On 4/29/06, Andrus Adamchik <[EMAIL PROTECTED]> 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
