<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:12pt"><div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;">+1 to XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX<br><br>I find myself looking at console logs of all five servers and looking at the mysql and SQLite prompt for issues so the human readable one is my vote.<br><br>Perhaps you can give an example in the code of each of the three cases so we can look all think about how to make this least traumatic?<br><br>Charles<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Sean Dague <sean@dague.net><br>To: opensim-dev@lists.berlios.de<br>Sent: Friday, June 13, 2008 6:00:52 AM<br>Subject: [Opensim-dev] standardizing on uuid string formats<br><br>We have 3 serialization formats for a UUID<br> * XXXXXXYYYYYYZZZZZZ....<br> *
XXXXXX-YYYYYY-ZZZZZZ....<br> * binary packed version (used in the mysql assets table exclusively)<br><br>This is definitely confusing. One of the reasons that we got here is<br>that there never was really a defined standard, and things grew and<br>changed over time. One of the reasons that we are still here is that<br>until recently, doing database migrations between formats would have<br>been a lot of crazy logic. I'm hoping that the Migration support I just<br>put in (and switched both SQLite and MySQL over to) should fix part 2.<br><br>So, back to part 1. I think we should declare a standard, and work<br>towards getting everything in that standard. My suggestion, and<br>preference here is form 2: XXXXXX-YYYYYY-ZZZZZZ... for the following<br>reasons.<br> * It's very user readable, and like the format that people have come to<br> expect in the client viewer. As people like looking at their data in<br>
both xml and in the database, making it make more sense to them is<br> probably a good thing<br> * It's the native string format for LLUUID and GUID (system built in).<br> Using another format means lots of converting back and forth. <br> * It also occured to me this morning that the extra string in every <br> conversion might account for some of our extra overhead.<br><br>All opinions on the table are valid. I firmly believe that anything<br>that gets our data more self consistant will help with maintainability<br>in the project. Please throw in your views, and I'll queue this up for<br>future work.<br><br> -Sean<br><br>-- <br>__________________________________________________________________<br><br>Sean Dague Mid-Hudson Valley<br>sean at dague dot net
Linux Users Group<br><a href="http://dague.net" target="_blank">http://dague.net</a> <a href="http://mhvlug.org" target="_blank">http://mhvlug.org</a><br><br>There is no silver bullet. Plus, werewolves make better neighbors<br>than zombies, and they tend to keep the vampire population down.<br>__________________________________________________________________<br></div></div></div></body></html>