Re: [Modeling-users] (LONG) Other OR-bridges?

[Sebastien B. <sbi...@us...>]

> Apologies for my earlier comment w.r.t. Zope -- I had only read your
> doc, and the prominence of the ZModelization tool made me jump to a
> wrong conclusion.  What about if the doc be re-organized a little to
> separete "model concepts (ER)" from "your data description language"
> (xml) and from "how the ddl is used by the framework" and from
> "existing tools to manipulate the ddl"? I know, there's plenty to do
> already ;)

Thanks for your comments, I realize that the documentation is quite
obscure on that point. I'll take your suggestions into account asap.

> Having to write XML instead of an excel file is not a major issue --=
=20=20
> but it is less comfortable (but maybe the ZModel tool is even more=20=
=20
> comfortable?)

  Sure, using the ZModeler is much, much more comfortable than editing
  an xml-file. But I understand installing and launching Zope just for
  that can be a burden --I'm currently looking for an alternate
  solution.

> For large queries, can either of the frameworks do paging?  In
> Modeling you can get the count, but, if the count is big, can you
> specify to fetch N objects at a time (respecting the original
> qualifiers, and sort, if any) ?
>=20
> Can you sort? (This is done in the store or in the db (much faster))

  (I've no idea of what are the MiddleKit's capabilities on these point=
s)

  For both questions, wrt. the Modeling, answer is: not yet.

  1. Work on paging has not began yet,

  2. Modeling.SortOrdering is specifically designed for sorting purpose,
     to be used along with Qualifiers in FetchSpecifications, but for
     the moment it can only be used for in-memory sorts.

> I must say that this is a problem! I have not yet managed to install
> Modeling because i could get neither pgdb nor psycopg installed on my
> OSX machine, as for some reason they will not compile (am following it
> up on the psycopg list).  PyPgSQL is installed however... how
> difficult is it to add support to another adaptor such as pypgsgl?

  Not *that* difficult ;) I released 0.8.1 today, adding support for
  pypgsql. BTW, I am *very* interesting in hearing from your and others'
  experiences with the modeling and MacOS X (and windows as well) since
  the only OS I have at hand is linux.

> BTW, the DEPENDENCIES file in 0.8 is a null reference (to another=20=
=20
> non-existant file).

  Sorry, my fault: it was in the cvs-tree, I just forgot to include it
  in the distributed tarball --fixed in v0.8.1.

> Is the time spent in converting the response tuples to initialized=20=
=20
> objects?
> (If so, could also do this conversion "only when needed"?)
> Or in doing consistency checking? (Could provide an option to switch
> this off when fetching?) Anyway, optimizations would be for later but=
 it
> is good to know where and what could be speeded up.

  Well, I do not have in mind the exact distribution, but I can say that
  most of the time is spent in converting raw rows to objects, right.

  Being able to fetch raw rows that can be later converted to objects is
  indeed on the todo list (no ETA, still: it highly depends on users'
  requests :).

[...]
> So you mean you would have an objectstore cached in each user session?
> (Very memory expensive?)
> Or a shared application-level object store that all users that fetch
> would go through? (To modify they will have to refetch into a new sto=
re?
> Or this is where the new feature you link to about nested contexts=20=
=20
> comes in?)

Sure, both designs are possible, that's an architectural choice. Back to
your questions:

  1. [an ObjectStore in each session] yes, since each object store holds
     its own copies of objects, this can be memory expensive. Future
     features related to that topic includes:

       - trying to maintain the number of objects per ObjectStore under
         a given, user-defined, limit (I say ``trying'', because when
         all objects in an object store are modified it is definitely
         not possible to reduce the memory footprint)
=20=20=20=20=20=20=20
       - having a shared ObjectStore where mostly-read-only objects
         lives and are shared by all other object store. This is called
         a Shared Editing Context in the EOF.

  2. Now what if you decide to have a shared app.-level object store?
     The first consequence is that any modifications made by one users,
     including non-committed ones, will be seen by others ; by the way,
     modifications are made as usual on objects and do not require any
     re-fetch.

  > Or this is where the new feature you link to about nested contexts=
=20=20
  > comes in?

  It will, to a certain extend. I suppose you're thinking of having a
  shared (root) object store, with one child (nested) object store
  e.g. created for each user when modifications are about to be done. In
  this configuration, changes will not be seen by other users until
  changes made in the child are committed back to the parent (the
  parent/child configuration will really bring transactional abilities
  to the sets of objects). Last, fetching objects in a child object
  store that were already fetched in a parent obj.store is just as
  expensive as refetching already fetched objects in a single obj.store:
  definitely not as expensive as the first fetch, as shown in my
  previous message.

    However, even in the still-uncommited changes, the framework lacks
  an important feature which is likely to be the next thing I'll work
  on: the ability to broadcast the changes committed on one object store
  to the others (in fact, the notifications are already made, but they
  are not properly handled yet).

Last and although this is not directly connected to that topic, I'd like
to make an other point more precise: the framework does not implement
yet any locking, either optimistic or pessimistic, on DB's rows. This
means that if other processes modify a row in the DB, an ObjectStore
will not notice the changes and will possibly override them if the
corresponding object has been modified in the meantime.

> How about POM?
> Which could be interpreted as PyObjectManager, with the additional me=
rit
> of retaining an implicit credit to Apple, as well as to its=20=20
> non-american author...
> never know, it might one day become Le Big Pomme :-)

Very nice proposition, I'll think of it. Really!

        Best regards,

-- S=E9bastien.