On 4/29/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
> Try this - close the Modeler and delete $HOME/.cayenne/prefs/
> directory. I have a few ideas on how to improve preferences database
> robustness, unfortunately they didn't make it to 1.2.
Of the top of my head, I can suggest xstream as an (as far as I've
used it) a great serialization engine. If you have a settings
structure it'll run through all the object down to the leaves of the
tree and store literaly everything (including private fields) not
marked transient into an xml file. It's bidirectional, simple,
distributed under a BSD licence and it "just works"...with the added
bonus of having readable/changeable settings instead of the (partialy)
raw binary content used now.
> Sigh... Merging over existing schema is indeed imperfect. We need to
> improve the Modeler in this area.
Focusing on a couple of the most simple cases might be a good starting
point. Interactive merger (anyone using gentoo? etc-update version
merger style?) of old and new version would be a bit more manual, but
it'd move the complex, less-than-perfect decision logic from the
modeler to the user.
The more I think about it the more ideas I get. Say it's possible to
identify a couple (5-15) of typical problems which surface when
reengineering the database. It might not be too much of a problem to
add some kind of actions to the window displaying project validation
errors or make a similar window. It reminds me of the eclipse
correction suggestion infrastructure, which I think is great.
> While I can't say when I'll be able to look into this, we can make it
> easier for the users to write (and contribute) modeler extensions.
> There are plans to switch Modeler to plugin architecture past 1.2.
> What I can do now is create a wrapper plugin environment around the
> 1.2 Modeler code in the Apache repository. If that works you'll be
> able to write your own merger code and use it without waiting for us
> to catch up with the Modeler tasks backlog.
Any mode of extensibility would be more than welcome.
I found a discussion on the topic I feel it's time to mention again:
the modeler and it's target development model (community based) are
perfectly suited to facilitate extensions and enable users like me to
get the job done without having to work with the modeler source itself
and possibly, along the way, help others with similar problems.
Regards,
Tomislav
This archive was generated by hypermail 2.0.0 : Sun Apr 30 2006 - 15:20:14 EDT