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

[Steve Swinsburg]

Ok. I think the values should be encoded then, and added to the main
scripts. The various i18n properties files have encoded values and there
are many of those.

cheers,
S


On Fri, Feb 22, 2013 at 11:03 AM, Matthew Jones <matthew at longsight.com>wrote:

> 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/20130222/b32fece7/attachment.html