[SQLObject] Namespace schemas

[<da...@eg...>]

Hi,

I'm writing about improving the namespace schema
situation for SQLObject. This is a topic that's been
brought up before (e.g. [1]_ and [2]_), but as far as
I can tell hasn't gained much traction.

My issue is exactly the problem described in [2]_,
and I'm using the fix described by Ben Bangert
in that thread, where I explicitly state the joinColumn.
It seems to me, however, that this is band-aid fix,
and SQLObject should be able to "do the right
thing".

I'm attaching a preliminary patch that addresses
this. Basically, what I've done is:

1. Add a field sqlmeta.schema and a getFQTN=
getFullyQualifiedTableName method. (I originally
tried making it a property, but I couldn't reconcile
the fact that SQLObjects contain a sqlmeta class,
not an instance).
2. Then go through the laborious but simple process
of going through and checking all references to
sqlmeta.table to see whether it should refer to the
getFQTN() instead. As has been noted before,
things previously "mostly worked" by just setting
table=schema.table, so most occurrences were
replaced. Only the join code still refers to sqlmeta.table.
(I actually haven't gone through any of the subdirectories
underneath sqlobject except for postgres.)

This brought up something that I hadn't bumped into
before, which was noted in [3]_, which is that joins
currently break if the column name and the target
table name don't match (the join code to compute
the joinColumn actually doesn't look at any column
names and uses only the target table name). Is this
intentional?

As I mentioned, this should definitely be viewed as
preliminary, but I just wanted to throw it out there.
I've included a basic test case also.

Finally, I just noticed that I've included an unrelated
but very small additional patch. This simply makes
sqlite:/:memory: URI's not cached - I think this would
be the more common use case (i.e., where you want
to manage multiple in-memory sqlite db's) instead
of where you get the same instance each time.

Thanks,
d


.. [1] http://thread.gmane.org/gmane.comp.python.sqlobject/2341
.. [2] http://thread.gmane.org/gmane.comp.python.sqlobject/3908
.. [3] http://article.gmane.org/gmane.comp.python.sqlobject/4227