good points. Could you elaborate on what you'd expect from > 2) join expressions aren't automatically created based on the DAL definition
Massimo On Nov 25, 9:48 am, Mirek Zvolský <[email protected]> wrote: > I think in relational databases (=in standard database world) foreign > key always should point to the primary key. > > Maybe PostgreSQL allows such something, maybe PostgreSQL (or other > database) allows a construction of primary key from more as one > fields, and so on, but I think it is not good idea to use such > 'feature'. Web2py is more strict and in this case I think this is good > (one reason, why I have chosen web2py). > > What you wait from such foreign key? > > I think foreign keys have only 2 goals: > 1) if record with some primary key is to be deleted, records with > connected foreign keys should be automatically delete (Cascade > integrity) or cleared (SetNull integrity). > 2) foreign key together with associated primary key can help > automatically prepare join expressions, if we use DAL(database > abstraction layer) instead of raw SQL. > > To previous 2 points I think, Web2py has problems or things which can > be improved in the future: > 1) SetNull integrity is not supported yet > 2) join expressions aren't automatically created based on the DAL > definition > there is a third problem here, > 3) Web2py turns on references support immediately after each table > definition (correct solution is: after all tables are defined). From > that reason you never can implement more complex database models in > web2py. > > So we can see, using of 'reference..' field type give us no advantage > at this time. > You can use 'integer' type instead. The only thing you need to program > is deleting integrity at application level. > > So I think using of 'integer' for the foreign key is solution for your > problem. > > Or, 2-nd possible solution, you can have, if you will re-evaluated > article.journal_id to point to journal.id. It's possible, because > journal.id is unique of course, and journal.ouid should be unique too > (because otherwise you have serious problems). > Such re-evelauting is same, as you can find in Web2py sources, where > replication is handled. > See "CSV and Remote Database Synchronization" in 6-th chapter of > Web2py book. uuid there is in similar role as your journal.ouid, but > foreign key in this example always point to .id field.
