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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

        Hi,

Mario <ma...@ru...> wrote:
> I am aware (and experimented with) another such layer for python,
> MiddleKit included in Webware (http://webware.sourceforge.net/) but
> may be used outside of it. It also is inspired from WebObjects' EOF,
> but seems to take a more pragmatic approach and providing a CSV model
> definition format from which tables and classes are generated. Are you
> familiar with this package?  How would these two frameworks compare?

  I must say that I've been told of the MiddleKit, however I never
  actually tried it --my comments will be derived from the online
  documentation and after a quick look at the source code. Since you are
  experimented with the MiddleKit, please correct me when I'm wrong.

First at all, and answering your previous message, the Modeling
Framework is NOT tightly dependent of/linked to Zope ; only the Modeler
needs Zope. The models used by the framework are xml-models, so it is
possible to write them without having access to the ZModeler (just the
way you write csv-models for use by MiddleKit, using your favorite
editor ; that's not *that* straightforward, though).

  Comparison between the two frameworks is not an easy task because I do
  not have real-world experience with the MiddleKit Framework. However,
  examining the documentation, I can try to highlight some facts:

  - both are indeed inspired by WO's EOF (the modeling currently sticks
    to the same API than the EOF's)

  - Regarding models:

      - MiddleKit seems to support class inheritance, and so does the
        Modeling it (in a limited manner, though: only horizontal
        mapping is supported for the moment being, I dont know what the
        situation is in MK)

      - types 'enum', 'bool' are not supported out-of-the-box by the
        modeling framework, but can easily be expressed by custom
        business-logic. Both do not support binary data types/BLOB/etc.

      - both can generate SQL code for DB-schemas and python code ready
        to be used

      - both do not support many-to-many relationships automatically

   - Regarding the frameworks' capabilities:

      - the modeling has a built-in query langage which is automatically
        turned to SQL query
        http://modeling.sourceforge.net/UserGuide/ec-fetch-object.html

        -- I could not find something like this in MiddleKit (except, of
        course, fetch all data then python-filter the results) Note:
        marked as FUTURE in MiddleKit.Run.ObjectStore

      - the modeling provides all ACID properties ; I cant tell for=20
        MiddleKit
        (ACID: Atomicity, Consistency, Isolation, and Durability see
         e.g. http://www.zope.org/Wikis/ZODB/guide/node12.html for deta=
ils)

      - the 2 object-relational mapping cores (driven by ObjectStores in
        both cases) are automatically triggered in both cases,
        maintaining the details of objects persistence ``largely behind
        the scenes'' (quoted from MK's doc.)

   - Misc.

      - installation: it seems that MiddleKit can be easily installed ;
        installing the Modeling requires quite a bunch of third-party
        packages (see the file DEPENDENCIES), including the WebWare's
        Cheetah ;)

      - Supported DB: MiddleKit: MySQL, MS SQL Server
                       Modeling: mysql, postgresql
=20=20=20=20=20

Mario> Any ideas of performance? For example, on a fetch of a 100, 1000,
Mario> or so objects, what is the difference between going thru DBAPI
Mario> directly, and going through this bridge?Have you ever had the
Mario> opportunity to get a feeling for this in some way?

That's exactly the kind of things I'd like to add to the documentation
online. These are the results of some quick tests I just made so that
you can figure out:

  [Computer: AMD Athlon XP 1.5Ghz, 512 Mo RAM, HDD on IDE]
  Tests made with postgresql and python running on the same machine
=20=20=20
  On a sample table having 21 attributes (mostly varchars 255 or so) and
  1423 rows, these are the raw times of fetching all the rows (select *
  from TABLE):

                                      python2.1    |  python2.2
                                  -----------------+-------------------
   w/ Modeling (using psycopg):    ~6.7s / 0.75s   |   ~5.4s. / ~0.60s
   w/ psycopg: (execute+fetchall): ~0.11s/ 0.11s   |   ~0.11s / ~0.11s

       Note: the first figure corresponds to the first fetch, the second
             one to subsequent ones.

   Remember that the modeling returns fully initialized objects (just
   like the MiddleKit does) and that psycopg returns raw rows. However,
   the factor is quite a big one and you see a big difference. By the
   way you'll notice that when objects are already fetched (even using
   different qualifiers), the framework detects it and fetches
   significantly faster (nb: any changes previously made to an object
   are not discarded).

   One big conclusion out of this is that is definitely not a good idea
   to use the modeling framework in e.g. a cgi script: initialization
   and fetch times would be too expensive. But desktop applications or
   web-app. build on any application server (if it provides a mechanism
   for dealing with sessions) do not suffer these init. times, and can
   largely benefit from the framework.

Last, 2 applications using the modeling have been successfully put in
production for three months. One is a zope-based web app. dedicated to
the supervision of doctors in duty for the french emergency services and
associated services, the other one is python-gtk-based app. for
bookshops' stock and sales management (size of the currently installed
DB: ~160Mo).  More details about these projects will be put online in
the next weeks, hopefully.

        Important ``detail'': they both use a non-released-yet version
        of the framework, v0.9, planned to be released before the
        15/02/03, or sooner if I find time or if you insist!  This
        release will be made of bug-fixes and enhancements, including
        Feature Request 617997
        [https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D=
617997&group_id=3D58935&atid=3D489338]

> A suggestion, if I may. How about an easily recognizable and short na=
me,
> such as PEOF (python EOF) ?

Well, this is exactly where I feel touchy... I know the name is not a
good one, so I'm opened to any suggestions, but I do not know if it is
ok to call it python-EOF since EOF is a trademark.=20
=20=20=20=20=20=20=20=20
-- S=E9bastien.