Just one question? Why not use WO for sql generation? It works very
well and I have lots of experience with it. All my projects create
their own DB structure if it does not pre-exist. It would have the
benefit of consistency.
Pierre
On 13-Jul-06, at 4:16 AM, Mike Schrag wrote:
> For the curious, here's my tentative plan for EOModeler:
>
> Pretty Much Done
> * data model (reading, writing, loading dependent models, prototype
> support, etc) including notifications (for syncing UI components as
> it changes)
> * model browser (== 'tree view in EOModeler)
> * entity browser (== entity list table in EOModeler)
> * attribute browser (== attribute list table in EOModeler)
> * relationship browser (== relationship list table in EOModeler)
> * relationship editor (== relationship inspector in EOModeler)
> * user info editor (shared among several object types in inspectors)
> * java generation (wolips integrates with EOGenerator for java
> generation)
> * entity editor (excluding stored procs)
>
> Phase 1.0 To-Do's (sure things for WWDC)
> * adaptor info editor
> * attribute editor
>
> Phase 1.1 To-Do's (pretty must essential, but might be annoying)
> * SQL generation (this is the big one -- I'm hoping to be able to
> use Cayenne's code for this) -- It's the trickiest because it
> requires the eclipse plugin to talk to a JDBC driver that isn't in
> its own classpath (it's in the project's classpath). This is the
> one I'm least looking forward to :)
>
> Phase 1.2 To-Do's (really nice to have, but not technically ESSENTIAL)
> * fetch spec editor
> * flattened relationship editor
>
> Phase 2 To-Do's (probably post WWDC)
> * stored procedure browser/editor/etc
> * diagram view (Eclipse has the Graph Editing Framework (GEF) that
> should provide most of this, but I'm pushing it off for now)
> * sql data browser (though if i can do generation, this might not
> be a big deal)
> * schema syncing
>
> ms
This archive was generated by hypermail 2.0.0 : Thu Jul 13 2006 - 10:29:50 EDT