[ZODB-Dev] AdaptableStorage and ZClass instances

[Shane Hathaway]

Roch=E9 Compaan wrote:
> On Thu, 13 Feb 2003 15:47:38 -0500
> Shane Hathaway <shane@zope.com> wrote:
>=20
>=20
>>However, at configuration time, you have access to the classes of the=20
>>objects to be loaded/stored.  During configuration, you could take the=20
>>opportunity to automatically configure mappers and gateways based on=20
>>class inspection.
>=20
>=20
> Can I only access the class at configuration time? Can't one
> get access to the class at runtime through the MetaTypeClassifier?

Yes, you can.  There could be some interesting introspection=20
capabilities there.  (Note that MetaTypeClassifier is specific to Zope2.=20
  I expect other applications to use a different kind of classifier,=20
such as mapper_std.FixedClassifier or a custom classifier.)

>>Application code might look very much like the=20
>>SQLObject example (see Christian's post), except that classes would use=
=20
>>ZODB.Persistent as a base class (rather than SQLObject) and the same=20
>>code would work in regular ZODB.
>=20
>=20
> Mmm, I don't know if I want to put any storage specific details in my
> application code just to make the OR Mapping work. What I think is
> genius about AS is that I can keep writing apps in the way I'm used to
> and in a way that fits the framework iow I don't have to subclass from
> this or that to persist my classes. I'd rather do more work on the side
> of the OR mapper and teach it how to persist objects in my problem
> domain.

Ok, I definitely agree with that.

> For a start one can definitely have a SQL base class that implements
> basic load and store methods which leaves you with only having to
> specify sql strings in the subclass, like Rocky suggested.
>=20
> But then one still has to write SQL for each class that you want to
> persist. My idea was to have a default properties gateway that generate=
s
> SQL at runtime for all classes that doesn't have a specific gateway.
> This seems problematic if one doesn't have access to the object and
> since this is a default gateway one wouldn't now anything about the
> class either. All one really needs is the classname and the property
> types and values on the object.  Is this at all possible?  The classnam=
e
> can then be used in the load and store methods of the gateway to query
> the right table and property types will be looked up in a typemap for=20
> the RDBMS.

This will work if the serializer does all the property introspection=20
ahead of time.  Ideally the class name should be managed exclusively by=20
the classification mechanism, but for simplicity I would suggest=20
ignoring that requirement initially and forging ahead. :-)

Shane