On Apr 29, 2006, at 12:48 PM, Tomi NA wrote:


I've finaly gotten a bit of time to look into it and concluded the following:
- the relationships weren't reengineered correctly because I was using
the 8.0 driver with a 8.1 database
- I was using the wrong driver because the classpath properties can't
be saved properly (I change them and during runtime they're fine, but
after I rerun the modeler, they're back to the old, incorrect
properties).

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.


- there's still some work to be done on "inteligent" schema reengineering.

So, the first two points are a confirmation that there are no loose
ends concerning the postgresql adapter.

This is good to know.

The last point, however, is the one I want to focus on now.

Simple use case: in an existing database (with a reengineered model)
add a new table with a simple primary key and add a foreign key to an
existing table referencing the new table primary key.
Reengineer the database, override all objects (this is was done on a
testing database) and the db-entities are perfect, but you get stuck
with all the previously existing relations between object entities
doubled - the old relationships remain but are invalidated by the new
ones. Why is that?

Sigh... Merging over existing schema is indeed imperfect. We need to improve the Modeler in this area.

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.

Andrus


Reply via email to