#5 SQLObject should not require special table or column names

[Gregory P. Smith]

In a future version of SQLObject, please remove the
dependancy on specific column or table naming schemes.
This will allow the library to be used with existing
databases that may not share the same database naming
conventions that the SQLObject authors prefer.

Examples:

-------------
create table snake (
id SERIAL NOT NULL PRIMARY KEY,
name TEXT
);

create table snake_photo (
id SERIAL NOT NULL PRIMARY KEY,
pathname varchar(255),
snake INTEGER
);
-------------

In the above example a snake can have multiple
snake_photos. In 0.3 that relationship could not be
expressed because the name of the linking column in
snake_photo is "snake" rather than "snake_id" as
SQLObject currently requires.

I propose doing what other object database libraries
do: Allow relationship definitions to specify the name
of the column used for linking. defaulting to
'snake_id' is fine, but an optional columnName='snake'
argument would be ideal.

MultipleJoin('snake_photo', columnName='snake')

Reasons:

I recently went searching for python object database
mapping libraries to use in a new application being
written for an existing database (built and populated
using perl's equivalent object database Class::DBI
library).

The two libraries that I found were "SQLObject" and
"orm" (http://www.tux4web.de/orm/). SQLObject had a
better looking website and online documentation so I
initially started looking at it but found that it would
only work for databases already following its implied
naming convention.

Another suggestion, provide human readable relation
setup function names. rather than MultipleJoin, call
it HasMany. (see the perl Class::DBI module for
examples of how readable that can make things).

[Bruno Trevisan]

Logged In: YES
user_id=800834

No comments or anyone willing to solve that?
This bug is very important so we can broader the use of
SQLObject. I'm having the same kind of problem and I would
like very much to know if you are going to solve this one.

[Ian Bicking]

Logged In: YES
user_id=210337

Yes, it'll get solved at some point. Foreign keys are
factored in a slightly wonky way right now, though the
changes would not have to be large. I'm afraid I just
haven't gotten around to it.

[Oleg Broytman]

Logged In: YES
user_id=4799

There is joinColumn.