Re: [SQLObject] Joins/FKs with bad IDs

[Luke O. <lu...@me...>]

As a short partial answer to myself:

We really only encounter this when we have testing/temporary databases, as I
agree strongly with Edmund that it is the constraints that give a database
meaning.

However, I would like to see a decent constraints system built into
SQLObject/Python, rather than relying on the database. Just was I have
obviously been pushing towards a python-side transaction system, etc. My needs
are typically the inverse of Edmund's: flexibility to use Python exclusively
but need to run across a variety of backends occasionally, and the fact that
I'm not a fan of most databases' 'trigger'-based procedural constraints
systems. I also think (don't know yet) that having python-side knowledge of
the constraints of the system will make dealing with these errors in an
intelligent manner

Now, it would be nice to simply augment the DB's constraint system if possible,
since I appreciate the fact that other tools touch the DB (heck, that's where
our bad IDs that started me talking about this came from..) Not sure how
feasible that will be beyond adding them to the creation SQL where there's a
conceptual match. I'm in the midst of re-reading CJ Date's "What not How",
which applies so directly to this issue... tangentially, I'm also leaning
towards the suggestion of supporting nested types, ala the Point example,
although I need to think it through for myself...

(I think my mind is slowly trying to figure out how to make SQLObject into an
implementation of Date's 'real' relational database / 'D' from Third
Manifesto, although i'm not at all sure yet. Reading 'What not How' again is
tying into a discussion I've been having on #python about static typing as a
way of declaring invariants about a system... that's what constraints are
too... must slow down the thoughts. :)

- Luke