Re: [SQLObject] Join tables

[John B. <jb...@dr...>]

Ok :-)

So please provide me with some code that will do my Ward/Constituency/Area
and 'something has many Areas' example... :)


J

On Tue, Nov 11, 2003 at 11:14:40AM -0600, Ian Bicking wrote:
> On Nov 11, 2003, at 4:20 AM, John Baker wrote:
> > If SQLObject is to be aimed at a very limited set of solutions, that 
> > don't
> > lend themselves towards proper OO programming, then perhaps clearly
> > stating this on the website would be a step forward. But at this point 
> > in
> > time, without superset mapping, you cannot model anything more than
> > trivial relationships. This makes it rather unhelpful, which is a shame
> > because it's actually quite easy to use.
> 
> You have to understand, it's easy to use because the mapping is simple 
> and clear.  I am trying to avoid frameworkification in SQLObject, which 
> is a difficult task.  To me, exposed object hierarchies are one of the 
> creepers which can overwhelm a project if left unchecked.
> 
> Now, I'm not sure if that's the case with this example, since the 
> object hierarchies we're talking about are in user code, not the 
> library code.  Still, I'm wary of all things inheritance-related.  Call 
> it the Zope syndrome.
> 
> My intention with SQLObject is not that it be all things to all people, 
> but rather that you can build all things on it.  The more complex 
> SQLObject is, the more disconnect there will be when the complexity of 
> your problem doesn't match the complexity of SQLObject.  As it is 
> SQLObject is clearly an easier foundation for building superset objects 
> than the DBAPI.  To do so it may be a little ad hoc right now, but you 
> have to build ad hoc designs before generalizing anyway, and a little 
> ad hoc design never killed anyone.
> 
> Maybe having done that you'll desperately want to generalize this 
> particular recipe.  I can only say that I would be much happier seeing 
> it phrased in an explicit manner using composition of objects, rather 
> than inheritance, perhaps because I don't treasure inheritance the way 
> a "real OO programmer" might (which is true), or perhaps because I 
> dislike false cognates and subtle disconnects.
> 
> > To the developer, how the data is stored is totally irrelevant. But 
> > when
> > your developer can't actually model relationships because the system of
> > persistence is restrictive, then we have a problem. I've already 
> > provided
> > two or three examples that clearly demonstrates that SQLObject can't do
> > what I want it to do, and I'm hardly trying :-)
> 
> FWIW, you don't have to code those examples as inheritance, and I 
> naturally wouldn't do so.  Composition is quite powerful, even if 
> mundane, and is pleasantly explicit.
> 
> > And as we all, as good OO developers know, if you build on poor
> > foundations, you regret it later in life.
> 
> As all good agile developers know, you make it up as you go along ;)
> 
> --
> Ian Bicking | ia...@co... | http://blog.ianbicking.org
>