Re: maven plugin for importing DB schema

From: Kevin Menard (nirvdru..mail.com)
Date: Sat Apr 11 2009 - 11:58:09 EDT

  • Next message: Tore Halset: "Re: how to add a column"

    Hi Adrian,
    I don't think anyone is disagreeing with the value in either a unified
    codebase or in automation tools. It's simple matter of resources. We have
    about a half dozen active developers at any given time of which a percentage
    of that is working on code. While the project has its priorities, so do
    individual developers. I know that may sound odd, but it's actually very
    hard to motivate someone to work in their free time on something that may
    not directly benefit them. In my current situation I do no commercial work
    with Cayenne in any capacity -- I work on it because I like the project.

    So, as things are a volunteer effort the choices tend to be one of three:

    - accept that a given feature may not added quickly (if at all)
    - try to work on the feature yourself (the dev team is always willing to
    help)
    - consider sponsoring development on a feature (this has worked in the past)

    As it stands with the DB import tools, we are firmly in the first of those
    three. I'd be happy to work with you on the second point if you'd like.
     And if you'd rather sponsor a feature, we can explore that avenue as well.
     As you can see, the bullet points also plot a natural continuum between
    cost for me to cost for you, in terms of development time, development
    capital, and completion time. 

    -- 
Kevin

    On Sat, Apr 11, 2009 at 10:23 AM, Adrian A. <a.adrian.tec..ooglemail.com>wrote:

    > >
> > I'm not sure the duplicate work is coming from.  No one else has picked
> up
> > the issues.
> >
> Well, from the user's perspective, the issues are one interesting and
> somewhat nontransparent thing, i.e. many issues seem too big to be
> implemented by the community (I suppose in a commercial project the issue
> would be broken into several small sub-issues that are easily doable). So
> just the pure assignment of an issue doesn't show how things are going, so
> that others users to pick small parts of it on the way and help.
>
> It's also not as simple as just refactoring the modeler code.  DbLoader
> > requires a delegate that handles the addition and removal of object and
> DB
> > entities and currently there's a lot of code tied into the UI from that
> > delegate.
>
> I saw that it's quite complicated for what is supposed to do (but this
> might
> be simply because I'm not used to the code, or was expecting something else
> :) ).
>
>
> >  I'm not convinced that abstracting all of that out is going to
> > make the code any clearer.
>
> I still think this should be the way - the entire reverse engineering
> process should be UI independent so that there aren't 3 different
> implementation with 3 different places to fix bugs or do improvements.
> Also IntelliJ is very smart at helping with refactorings (I see that your
> project already has free licenses for it)
>
> I think, the success of the Cayenne (and Modeler) depends to great degree
> on
> how smart is the reverse engineering step - the smarter it is, the less
> manual work has the user to do, so the greater the user satisfaction is.
> With scenarios of over 50 tables, manual intervention is simply a pain
> (from
> what I experienced so far :( ).
>
>
> > So, I'm tackling this on a one-off basis first,
> > seeing what's common, and then taking it from there.  Given that I drove
> > primary development on all of the maven plugins and a large part of the
> ant
> > ones, I feel this is the best approach to take.
> >
> > If you'd like to help out testing CAY-1029, feel free to start up a
> simple
> > project in maven.  If not, that's fine, too.  I'll get to CAY-1197
> someday
> > and I'll set up a simple project in ant.  There are people interested in
> > both so I should get feedback one way or another.
> >
> > Incidentally, the maven plugins and ant tasks are a great place for a
> > community member to supply a patch.  In fact, it's how I got started with
> > Cayenne.  They're abstracted enough out of core that the opportunity for
> > damage is fairly minimal.
>
> I will give it a try.
>
> I think however that to the same category of "smart reverse enginnering"
> should be these too:
> #1. https://issues.apache.org/jira/browse/CAY-154
> (better said the UI independent code  - i.e. to detect automatically
> many2many and flattern where appropiate - if a setting for this is active)
> #2. https://issues.apache.org/jira/browse/CAY-400
> (to be able to get the comments from the DB attached to the object and DB
> entites)
> #3. https://issues.apache.org/jira/browse/CAY-209
> #4. https://issues.apache.org/jira/browse/CAY-850
> (or something similar - i.e. where there's a "name matching" but no
> concrete
> foreign key, to add a single directed  relationship. E.g. many tables have
> "created_by_user_id", but no FK to the user)
> #5 Singularize of table names (if a setting is active)
>
> As you can see, for many of the above feature requests, a seprated and UI
> independent reverse engineering step would allow to make it happen quite
> faster (since it would be done and tested in a single place - the rest: UI,
> ANT, and  Maven being just "wrappers" :) )
>
> Thank you,
>
> A.
>

    This archive was generated by hypermail 2.0.0 : Sat Apr 11 2009 - 11:58:42 EDT