On Saturday 31 March 2007 08:44, Carl Karsten wrote:
> johnf wrote:
> > On Saturday 31 March 2007 08:27, Paul McNett wrote:
> >> Carl Karsten wrote:
> >>> If it is an option, use client side GUIDs for your keys. life is so
> >>> much better. the only regret I have is having to not care about people
> >>> who have to use all the other kinds of keys. well, I care, but can't
> >>> justify spending time on addressing the problem.
> >>
> >> I agree wholeheartedly. Client-side UUID's are definitely the ticket,
> >> although they do take more bits per field than ints. I'm particularly
> >> wasteful as I don't bother compressing the 40-byte string returned from
> >> dabo.lib.getRandomUUID().
> >
> > I'm using Postgres and the data type "serial" is built-in. It's fast
> > and the number is huge.
>
> Um, I have no idea what you mean. well, I have an idea, but not really sure
> how it relates to your problem.
>
> Carl K
This is what I mean:
The serial type is a autoincrement field. Actually it is a sequence function.
All sequence functions have three methods available:
1. nextval()
2. curval()
3. setval() - setting the min and max (not sure about name for this one)
This is how it relates to my problem:
The problem as I see it revolves around AutoPopulatePK , requery of children,
and the order of the user subclass hooks. One other thought, dMemento's may
not be working correctly.
If AutoPopulatePK=True then the temp PK is set to a string type. And before
my app can change the PK type (to integer) using a user defined hook (like
onNew) Dabo requerys any children with PK set as a string. Therefore,
nothing can be done without changing the order of hooks in Dabo.
Setting AutoPopulatePK=False is causing other issues with dMemento's
routines. In fact setting AutoPopulatePK=False causes dMemento to return
a '0' for changed rows.
--
John Fabiani
©2007 johnf |
