sql backend - guid

Lincoln A. Baxter lab at lincolnbaxter.com
Wed Jun 17 22:35:17 EDT 2009


One note about UUIDs. I know Derek knows this, but for those who may
not: UU="Universally Unigue".  There should be a virtual impossibility
that any number of UUIDs generated at the same time or different times,
on the same hardware are different hardware will be the same in our life
times.  UUID generators that follow the OSF DCE 1.1 specifications are
accepted as generating valid (unique) UUIDs. See
http://en.wikipedia.org/wiki/UUID.  Or type "man 3 uuid" on a linux
system with e2fsprogs on it.  On windows there is a system service
library routine called "UUIDCreate()" that also (I beleive) follows the
DCE rules.  Many windows folks (and Oracle Folks) call this a GUID. 

uuidgen on linux uses the e2fsprogs library.

Lincoln

On Wed, 2009-06-17 at 21:25 +0100, bdebrabant wrote:
> Hi Derek,
> 
> Thanks for you reply.
> 
> 
> Derek Atkins wrote:
> > Hi,
> >
> > bdebrabant <bdebrabant at gmail.com> writes:
> >
> >   
> >> Hi,
> >>
> >> I've recently upgraded to gnucash 2.3.1, and am now using the postgresql
> >> backend.
> >> The speed has significantly improved (compared to the xml backend),
> >> especially while generating reports, which is really good news.
> >>
> >> I was also thinking of populating the price database directly, from a
> >> second database I'm maintaining.
> >> Hence my questions:
> >>
> >> 1) It's not really clear why guid are characters, while it could have
> >> been quite easy to use integers (& autoincrement)...
> >>     
> >
> > GUID == UUID == 128-bit number.  It's much better to encode that in
> > radix-32 than in decimal.
> > Each object needs to have a stable GUID, and the SQL and XML need to
> > remain equivalent.
> >
> > Also, objects need to be uniquely identified regardless of type, so
> > autoincrement doesn't work (unless you have a single "objectID" table
> > that just gives you a global GUID in the DB, but that's pretty silly
> > when just using a real GUID is fine.
> >
> >   
> The question was actually: why do we need to have this encoded?
> To me, a numeric key would have been much easier to generate but also
> more useful to sort the data.
> I'm not event sure such an objectID table would have been required, as
> it could have been shared across types.
> 
> >>     Also, for some tables, like the price table, I'm not sure who
> >> usefull a primary key on guid can be.
> >>     
> >
> > It's useful because lookups are usually based on GUID.
> >   
> I see...
> However, it doesn't prevent people to add several prices for the same
> commodity for a given timestamp/source.
> 
> >   
> >>     Wouldn't it be better to have a primary key on
> >> commodity/currency/date/source for instance?
> >>     
> >
> > No.
> >
> >   
> >> 2) Would it be safe to generate guid other than by calling qof functions?
> >>     Any idea how to do it?
> >>     
> >
> > Generally, yes, it's safe, but you should make sure they are
> > pseudo-random.  E.g.:
> >
> >   uuidgen | sed -e 's/-//g'
> >
> >   
> thanks, i'll try that
> 
> >> Thanks,
> >> Baptiste
> >>     
> >
> >   
> >> Please remember to CC this list on all your replies.
> >> You can do this by using Reply-To-List or Reply-All.
> >>     
> >
> > -derek
> >
> >   
> Thank you,
> Baptiste
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
> 



More information about the gnucash-user mailing list