[Building Sakai] Why is the SAM-787 conversion on its own in reference?

[Matthew Jones]

Yea, I think that was the reason too. This query was separate because if
someone edited the conversion script with an editor that didn't support
UTF-8, then these characters would save back incorrectly and wouldn't work
anymore, so we kept them separate so they wouldn't get messed up.

I'd commented that in the past I often hex encode all characters in
conversion scripts [1] because even running it sometimes there were
problems with UTF-8 characters, then easier to let the database decode it
(with rawtohex [oracle] or unhex [mysql]). It couldn't get messed up in any
case that way, but was impossible to change. However I'd forgotten how I
automatically did that (probably a perl/ruby script), and didn't have an
Oracle to test on so the quick fix was to leave that separate.

[1]
https://source.sakaiproject.org/svn/msub/umich.edu/ctools/builds/trunk/db-conversion/evaltemplateupdateraw.sql


On Thu, Feb 21, 2013 at 6:50 PM, Sam Ottenhoff <ottenhoff at longsight.com>wrote:

> I don't remember why it was kept separate.  Possibly because it contains
> lots of UTF-8 chars and the update needs to be run with a proper
> commandline UTF-8 connection.  I agree it's not a pattern other tools
> should follow.  So do we assume that the person running the update has a
> proper UTF-8 commandline connection, or do we keep it separate with
> explicit directions?
>
>
> On Thu, Feb 21, 2013 at 6:29 AM, Steve Swinsburg <
> steve.swinsburg at gmail.com> wrote:
>
>> Hi,
>>
>> Could someone involved in the resolution of SAM-787 comment as to why the
>> conversion for that issue exists in its own script in
>> reference/docs/conversion?
>>
>> First, it's a conversion for a single tool so really should be in the
>> tool itself if that tool distributes its own SQL (possibly as some sort of
>> doco/reference).
>>
>> Second, and most importantly, if its meant to be run as part of the
>> official upgrades (2.9.0 and 2.8.3), it should be part of one of the proper
>> upgrade scripts, not on its own since without a lot of digging, there is no
>> indication that this should be run in addition to the upgrade scripts. If
>> individual tool files are going to be added here, its going to be a royal
>> mess.
>>
>> IMHO, this SQL needs to be added to the 2.9.2 and 2.8.4 upgrade scripts
>> and the SQL file in question removed.
>>
>> Note I've sent this to all developers since there were many people
>> involved in the Jira, more than just the release team.
>>
>>
>> https://source.sakaiproject.org/svn//reference/tags/sakai-2.9.0/docs/conversion/
>> https://jira.sakaiproject.org/browse/SAM-787
>>
>> cheers,
>> Steve
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130221/944c4930/attachment.html