[Opensim-dev] EstateID from uint to UUID

[Stefan Andersson]

Tommi, Melanie,

 

I do agree that guid is the preferred identifier type. It reduces unintentional collisions between two separate schemas, whereas the 'autoincrement int' schema is known to be prone to messy collisions on merging and moving data.

 

I can definitively see scenarios where you would want to merge two estates into the same database and them colliding on estate id.

 

There is nothing stopping us from having two columns, one guid 'installation-wide estate id' and one 'grid-local estate id' int - but it would be messy, and I'm having problems seeing the benefit of it.

 

So, I agree with Melanies calling for a clear use case - a present situation that calls for this change before it's done.


Also - as Melanie also states, the estate id should be thought of as an identifier local to the grid - and furthermore, even if it was a 'guid', it would _still_ have to be thought of as a identifier local to the installation; No system should ever accept its internal lookup keys from a system outside of its trust boundaries. We do it today (because we really don't use 'trust boundaries' as a concept at all - and it will bite us in the ass eventually) - so a good start would be not to introduce more dependency on foreign key data.

 
Best regards,
Stefan Andersson
Tribal Media AB



 
> Date: Sat, 14 Feb 2009 12:27:05 +0000
> From: melanie at t-data.com
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] EstateID from uint to UUID
> 
> Estate IDs are not shared between installations. They don't need to 
> be Guid/UUID. That would just break pretty much everyone's web 
> frontends and also mess wirth the client.
> 
> -1
> 
> Melanie
> 
> 
> Tommi Laukkanen wrote:
> > I think this is a valuable discussion to have. My view is that all object
> > identifiers ought to be UUIDs as UUID type is developed specifically for
> > that with bullet broof unique id generation algorithm where as all other id
> > generation algorithms are either database specific or fail if you have
> > distributed service or both. If we want to prepare for distributing all our
> > systems then aiming for purely UUID based identification is a good step
> > forward. In understand that in practice it might be a very long time before
> > we can reach a point where all identifiers are of UUID type but if we
> > consider this to be a design principle then the resolution is immediately
> > valid for any new implementations we do.
> > 
> > On Sat, Feb 14, 2009 at 1:23 PM, Melanie <melanie at t-data.com> wrote:
> > 
> >> Estate ID is a purely local concept that is likely to vanish in
> >> newer viewers and the Hypergrid. There is no point in creating a
> >> double-lookup scenario.
> >> There is nothing that says that all objects must be GUID and no
> >> point in refactoring for refactoring's sake.
> >>
> >> Melanie
> >>
> >>
> >> Tommi Laukkanen wrote:
> >> > Hello
> >> >
> >> > LL viewer quirks we must conform to but as with many other objects the
> >> > primary key could be uuid and uint based id is kept around for ll viewer
> >> > compatibility? Maybe it gets too messy in the end to be worth the
> >> trouble.
> >> > One can consider it once we get to have custom viewers which are not
> >> leashed
> >> > by SL protocol limitations.
> >> >
> >> > regards,
> >> > Tommi
> >> >
> >> > On Sat, Feb 14, 2009 at 1:14 PM, Melanie <melanie at t-data.com> wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> the estate id _is_ a uint. It is not a UUID and was never meant to
> >> >> be a UUID. The client sends and expects a UINT.
> >> >>
> >> >> Melanie
> >> >>
> >> >>
> >> >> Tommi Laukkanen wrote:
> >> >> > Hello
> >> >> >
> >> >> > I am working on Estate NHibernate storage and noticed that EstateID is
> >> >> still
> >> >> > of uint type where as most of other objects have been converted to
> >> UUID
> >> >> > identifiers. Is anyone interested in tackling this refactoring from
> >> uint
> >> >> to
> >> >> > UUID. Its not a small job but it would make the database much cleaner.
> >> >> >
> >> >> > regards,
> >> >> > Tommi
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> ------------------------------------------------------------------------
> >> >> >
> >> >> > _______________________________________________
> >> >> > Opensim-dev mailing list
> >> >> > Opensim-dev at lists.berlios.de
> >> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >> >> _______________________________________________
> >> >> Opensim-dev mailing list
> >> >> Opensim-dev at lists.berlios.de
> >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >> >>
> >> >
> >> >
> >> > ------------------------------------------------------------------------
> >> >
> >> > _______________________________________________
> >> > Opensim-dev mailing list
> >> > Opensim-dev at lists.berlios.de
> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >> _______________________________________________
> >> Opensim-dev mailing list
> >> Opensim-dev at lists.berlios.de
> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090216/7e585dfc/attachment-0001.html>