Re: Improved EOModel support

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Sat Sep 06 2003 - 16:34:35 EDT

  • Next message: Andrus Adamchik: "Re: My background info"

    Hi Mike,

    On Saturday, September 6, 2003, at 02:59 PM, Mike Kienenberger wrote:
    > While I'm fairly certain that no one objects to improving the Modeler
    > to
    > better import EOModels, does anyone have any objections to extending
    > it to
    > export EOModel data formats (along with any other support necessary for
    > EOModels)?

    I certainly don't object, I will support any effort in this direction.

    > There's no reason why a Modeler tool has to be dependent on any
    > particular
    > database layer framework

    Agreed. Interesting that a few people suggested to use a UML based
    approach to modeling persistent objects with "export" function for all
    possible O/R frameworks. This discussion happened a few times on this
    list. E.g.:

        
    http://www.objectstyle.org/cayenne/lists/cayenne-devel/2003/03/0116.html
        
    http://www.objectstyle.org/cayenne/lists/cayenne-devel/2003/03/0118.html

    I haven't heard from anybody on any progress, and no code was
    contributed so far.

    > I've been able to create templates to export EOModels into (now
    > Oracle's)
    > Toplink,

    I would love to see TopLink export and (especially) import functions in
    the Modeler. Never started it myself, since I was always scared of the
    TopLink XML jungle :-) (lots of class metadata, CVS unfriendly
    meaningless XML index files, etc...)

    > and from what little I've seen, there's no incompatibilty between
    > Cayenne models and EOModels. (Which is a Good Thing since a database
    > model
    > should be conceptional rather than tied to an implementation.)
    >
    > I think the concept of EOModeler is great. I've used EOModels as
    > input to
    > templates that generate complete sets of web pages (Searchable/sortable
    > Report on Entity, Edit/Create Entity) without intervention. As I
    > mentioned
    > above, I've also used EOModels as a replacement for the Toplink
    > database
    > mapping GUI and model.

    Cayenne (both Modeler and framework) can be a good starting point for
    advanced class generation. Velocity templates were used from the very
    beginning for DataObjects generation (both with Ant and from GUI).
    There can be levels and levels of new functionality added to this
    process.

    > I "found" Cayenne's modeler because I just started an Sourceforge
    > project
    > (ORModeler) to provide a replacement to EOModeler that was not tied to
    > a
    > particular db platform. After having waited several months and having
    > performed another day of searches on EOModeler in an attempt to locate
    > an
    > EOModel-like project, I started my own. (It seemed like it might be
    > fun to
    > write an XML parser, and ORModeler seemed like a good project for
    > doing so.)
    > I only found the Cayenne modeler when I went looking to see if there
    > were
    > any open source implementations of a plist parser. Imagine my
    > surprise when
    > I found an entire Modeler.

    Umm... marketing is not our strong side :-(. We have an open position
    for a fulltime unpaid marketing director ;-). Seriously, I was thinking
    about doing some real promotion, like writing articles, doing
    presentations in JUG, etc. Unfortunately it all takes even more effort
    than writing the code. Now when I am finally back to freelancing, I may
    be able to dedicate more time to that.

    > So what I'm hoping is that I can close the ORModeler project and just
    > help
    > extend this modeler.
    >
    > I think if you add EOModel support, you'll get a lot of interest from
    > the
    > WOProject people, especially the WOLips people.

    You got me interested. I am a WOProject person :-). Seriously, just
    propose a list of detailed features on this list. We will be branching
    for Cayenne 1.1 soon, so it will all go there. Lets work for a while
    via patches, and if this is going somewhere, we will vote on commit
    rights for you.

    > You might even get some interest from the Toplink user community
    > (assuming
    > that there is one -- I can't find any trace of one) since there seems
    > to be
    > a lot of agreement that the Toplink Data Mapper Workshop tool is really
    > flakey (and coming from an EOModel perspective, it's unnecessarily
    > complicated on top of that).

    If not from the community, then from the individual unsatisfied TopLink
    companies and developers. Don't get me wrong - TopLink is mature and
    solid, but for me it became a clear example of why OpenSource is so
    important (e.g. once we discovered a bug in CLOB handling, and
    basically could not resolve this with Oracle, so I had to copy lots of
    raw JDBC code from Cayenne to work around this).

    Andrus



    This archive was generated by hypermail 2.0.0 : Sat Sep 06 2003 - 16:32:27 EDT