[Zope3-dev] ORM

[Jeffrey P Shell]

On Jun 28, 2004, at 10:04 AM, zope3-dev-request at zope.org wrote:
> Date: Mon, 28 Jun 2004 16:31:54 +0200
> From: Nick Bower <nicholas.bower at jrc.it>
> Subject: [Zope3-dev] Re: Relational Databases in Zope 2 and Zope 3
>
> Yeah great isn't it - my colleagues using that other OO language get to
> rave about Hibernate, meanwhile as a person with a year of Zope, I'm
> trying to scoop up any breadcrumbs I can about how to move past
> something called ZSQL methods. ;)
>
> Yes I also feel Zope ORM is something that's annoyingly lacking, but
> it's probably not a trivial thing to address either unfortunately.

I used to feel, vehemently, that Zope needed a good ORM story.  And I 
think that, in a sense, it has that now in APE.  Beyond that level, I 
don't want it any more.  I can understand that other people will, but 
we've found that a lot of our 'enterprise' applications have fared 
better under a different model than Object Relational.  Just like I 
think Zope X3 would be severely crippled if presented only as a content 
management system instead of a general purpose application 
server/platform, I think that Zope's external data management strategy 
would be severely limited if limited to Object-Relational.  {I do think 
that Ape is a good fit, since it fits nicely into the ZODB and thus 
into Zope's programming style}.

This is not to say that Object-Relational is bad.  Hybernate looks to 
be really really well done.  And I've been a huge fan of Apple's 
Enterprise Objects Framework (a NeXT product, now basically the heart 
of WebObjects).  But those systems are much more in depth and flexible 
than I've seen anyone come up with in the Python world ('Modeling' 
comes closest).

The recent experiences me and my company have had have leaned towards 
more of a D4 type system - dynamic, declarative, data-driven.  At 
least, towards my limited understanding of D4.  I've only seen that 
term come up a few times, but it seems to fit what we've been finding 
success with.  Our success has come from a more action-oriented 
approach, with table gateways and a large system of wrappers that 
transform data on its way in and out of storage.  This includes element 
level security declarations that can completely remove elements (deep 
in the chain, before they hit the user level) that a user can't see, or 
changing how they render - an editable widget, a plain string, or a 
value like "** not allowed **".  It's a complex, but not complicated 
<wink>, system that has proven very effective for a couple of large 
customers with very sensitive data.  I haven't seen any O-R system that 
would work the way we need them to, because the modeling/mapping is 
more sensitive to an action being performed (and by whom) than it is to 
objects.  The actions are like the 'EditView' in Zope 3.  They're logic 
that really deals with the behavior of a particular user interface view 
more than they are straight-up business logic.  Business logic is 
really modeled up in the rules and transformations that are applied to 
the data as it's getting prepared for and from an action.

Simpler, earlier versions of this system were written exclusively for 
Zope, and still followed the action-oriented principle.  SQL Methods 
were dynamically generated at run time to do INSERT / UPDATE 
statements, and simple SELECT's as well.  SQL Methods were also used in 
normal form for more complex SELECT queries, because they're great for 
that (in my opinion.  sqlgroup and sqltest are my friends, if not the 
friends of others).  SQL Method maintenance just gets annoying for DML 
statements.  We later applied the same patterns (and basic system) to 
an LDAP administration system with relative ease.  All of this was 
before the larger project mentioned above, where the action-oriented 
system was applied to larger enterprise requests (and removed from 
Zope, except for some gateways to connect the two).

> BTW - First impressions to me of SQLObjects (thanks for info) were that
> the suggested method for modelling joined classes didn't look very well
> conceived.  Furthermore, embedding RDB semantics (classMember =
> StringCol()???) in your business objects looked simplistic when POJOs
> and even Zope objects try and abstract this sort of thing elsewhere.
> Maybe that's too harsh comparing apples and oranges, and as I said, 
> I've
> never used it.

That's why I think that APE is a nice fit.  If you really care about 
your business objects being business objects, as much abstraction from 
the storage mechanism as possible is nice.  XML and Object Databases 
can be just as fine a fit as Relational, if not better, for certain 
purposes, and there are other database management systems out there as 
well that may give you great storage and query benefits.  I know that 
the reality is is that most data is in an RDBMS, but it doesn't have to 
be!

I think SQLObjects is a fine system for small and even mid sized 
applications, but it doesn't scale to the levels I and my colleagues 
have needed.  And scalability has been a growing concern of ours.  And 
having a system that is abstracts storage away from persistence, except 
where heavy querying was required, has been good for us.

--
J.Shell
jeff at bottlerocket.net