[Opensim-dev] Code changes to revert to non-hyphenated strings - is this the right way forward?
Stefan Andersson
stefan at tribalmedia.se
Fri Dec 21 07:02:53 UTC 2007
Justin,
> 1. Is it, in fact, more sensible to get some method for doing this on > LLUUID itself (ToStringRaw())? Doing it this way is very non-OO, > although might be better if you think such methods should live outside > of the objects themselves.
Sorry for re-iterating this, but the conversion is a function of the serializing CONTEXT - not the OBJECT itself.
Consider all the different serializations, ToString, ToStringHyphenated, ToXml, ToXmlString, ToReader, ToHtml, ToHtmlHeader, ToByte[] et.c. (and then add Parse and From...)
If the base objects would know about the demands of all of these, they would be coupling culprits in deed. That is why we have been moving away from that approach for a number of years now.
OO is not an end, but a means. Even so, one could argue that this is in fact object oriented, but it's the serialization that is the focus, not the data.
> 2. I notice, at least in MySQL and SQLlite, that all the database > tables could already handle uuid strings with 36 characters (the asset > table being the notable exception). Are we better off keeping the code > as is and asking users to manually convert their databases if they want > to retain their data? Downside: user conversion & ToString() remains, > as well as some conversion work. Upside: potentially Path Of Least > Resistance, fewer introduced bugs in the conversion process.> > This option still requires some manual change (e.g. to Inventory code > which hardcodes initial UUIDs) and needs the binary 16 id store of the > Asset table to expand to 18.
Just to take that discussion; It seems the database stores either VARCHAR or BINARY - one is a waste of space and the other is just plain wrong
On most Databases you can't index on binary fields (I don't know if that's the case with MySql et c.) so the right way to go is
CHAR(36) on systems that don't have a Guid type and UNIQUEIDENTIFIER on those that has.
This is an excellent opportunity to remedy that too.
/Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20071221/6c8449b0/attachment-0001.html>
More information about the Opensim-dev
mailing list