Legacy Database Id Field

[villas]

Specifying Alternative Id Field: I notice some other frameworks allow
the developer to specify the name of the Id field in the table
definition etc. Something like: db.primarykey = 'other_id'. This
makes it much easier to use with legacy databases, are there any
plans to implement that? The only alternative I could think of would
be to copy other_id to id with a DB trigger -- could that make sense
as a work-around?

Merging Records: In Cakephp for example, if you specify the id field
as char(36) the framework authomatically inserts UUIDs. This is very
handy when merging two tables together (e.g. from different DBs). It
eliminates the need to specify id ranges for tables to avoid
'collisions', which would of course be a ugly hack, and still
dangerous (ids could overrun their ranges). Any ideas for a Web2py
solution to that?

Many thanks.

[mdipierro]

On Aug 26, 9:34 am, villas <villa...@gmail.com> wrote:
> Specifying Alternative Id Field:  I notice some other frameworks allow
> the developer to specify the name of the Id field in the table
> definition etc.  Something like:  db.primarykey = 'other_id'.  This
> makes it much easier to use with legacy databases,  are there any
> plans to implement that?  The only alternative I could think of would
> be to copy other_id to id with a DB trigger -- could that make sense
> as a work-around?

yes, we are working on it.

> Merging Records:  In Cakephp for example, if you specify the id field
> as char(36) the framework authomatically inserts UUIDs.  This is very
> handy when merging two tables together (e.g. from different DBs).  It
> eliminates the need to specify id ranges for tables to avoid
> 'collisions',  which would of course be a ugly hack, and still
> dangerous (ids could overrun their ranges).  Any ideas for a Web2py
> solution to that?

yes, just "import uuid" and add a field

Field('uuid',default=str(uuid.uuid4()))



> Many thanks.

[villas]

> > Specifying Alternative Id Field:

> yes, we are working on it.

Without wishing to be too specific, any idea when: weeks or months?
In the meantime, do you think it would be feasible to use the idea of
simply copying the primary key to 'id' with a DB trigger?

> > Merging Records:  

> yes, just "import uuid" and add a field Field('uuid',default=str(uuid.uuid4()))

Well I was meaning to use an UUID as a primary key, but I guess
that's not on the agenda. As far as stopping duplicates though, it
seems good.

BTW I just bought the new edition of the book and congratulate you on
producing such a fine reference guide. Thanks so much.