Re: reverse engineering a postgresql database: no relationships detected?

[Tomi NA <he...@gmail.com>]

On 3/14/06, Cris Daniluk <cr...@gmail.com> wrote:
>
> Can you give the latest CVS a try before I mark this resolved? I added a
> "second pass" that should catch skipped relationships.
>

I'm using 1.2M12 (March 23rd) and I have the same issue I started with.
I've added a couple of fields as well as their respective foreign key
constraints, tried to reengineer just that one table and got no
relationships at all. I've just tried to reengineer overwriting everything
in the existing model and got a relationless model.

Has this been taken care of in 1.2B1?

t.n.a.

Re: reverse engineering a postgresql database: no relationships detected?

[Tomi NA <he...@gmail.com>]

On 5/1/06, Andrus Adamchik <an...@objectstyle.org> wrote:

> Anyways, I was just thinking out loud, as I am trying to find a
> better solution. One more idea - we should stop trying to be fancy
> and stick with Java standard preferences API as a least common
> denominator :-)

As far as I'm concerned, anything that works well (enough). In this
respect, I belive an idea borrowed from Einstein might be a good
guideline here: Make everything as simple as possible, but no simpler.
:)

t.n.a.

Re: reverse engineering a postgresql database: no relationships detected?

[Andrus Adamchik <an...@objectstyle.org>]

On May 1, 2006, at 5:51 AM, Tomi NA wrote:
> Not that I'm against trying new things, but do you know of any other
> application storing it's preferences in a database? It seems like a
> major overkill to me...but then, I don't know much about the specifics
> of the modeler code so take my comments with a grain of salt.
>
> t.n.a.

There is nothing special about the Modeler in this respect. And a  
standalone DB engine would indeed be a major overkill. Embedded DB on  
the other hand seemed like a good option and indeed performed pretty  
well (except for the occasional data corruption...he-he).

Anyways, I was just thinking out loud, as I am trying to find a  
better solution. One more idea - we should stop trying to be fancy  
and stick with Java standard preferences API as a least common  
denominator :-)

Andrus

Re: reverse engineering a postgresql database: no relationships detected?

[Tomi NA <he...@gmail.com>]

On 4/30/06, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> On Apr 30, 2006, at 3:39 PM, Andrus Adamchik wrote:
>
> >> Of the top of my head, I can suggest xstream as an (as far as I've
> >> used it) a great serialization engine.
> >
> > Good idea. Serializing preferences to XML may be a better solution.
> > Embedded HSQLDB proved to be too unreliable. And I guess we can use
> > XSLT transforms to version the preferences.
>
> Using Cayenne for preferences is great for a few reasons (1) you can
> do real queries and (2) updates are incremental. I guess if we go
> XML, we'll have to manually partition the preferences into smaller
> manageable chunks and use XPath. Oh well...

Not that I'm against trying new things, but do you know of any other
application storing it's preferences in a database? It seems like a
major overkill to me...but then, I don't know much about the specifics
of the modeler code so take my comments with a grain of salt.

t.n.a.

Re: reverse engineering a postgresql database: no relationships detected?

[Andrus Adamchik <an...@objectstyle.org>]

On Apr 30, 2006, at 3:39 PM, Andrus Adamchik wrote:

>> Of the top of my head, I can suggest xstream as an (as far as I've
>> used it) a great serialization engine.
>
> Good idea. Serializing preferences to XML may be a better solution.  
> Embedded HSQLDB proved to be too unreliable. And I guess we can use  
> XSLT transforms to version the preferences.

Using Cayenne for preferences is great for a few reasons (1) you can  
do real queries and (2) updates are incremental. I guess if we go  
XML, we'll have to manually partition the preferences into smaller  
manageable chunks and use XPath. Oh well...

Andrus

Re: reverse engineering a postgresql database: no relationships detected?

[Andrus Adamchik <an...@objectstyle.org>]

On Apr 30, 2006, at 3:19 PM, Tomi NA wrote:
> Of the top of my head, I can suggest xstream as an (as far as I've
> used it) a great serialization engine.

Good idea. Serializing preferences to XML may be a better solution.  
Embedded HSQLDB proved to be too unreliable. And I guess we can use  
XSLT transforms to version the preferences.

I've heard good things about XStream, but since Cayenne has its own  
XML coder, I'd say we'll stick with it (you know - all that stuff  
about eating your own dog food :-)). Decoder worked great for the JPA  
stuff I am doing now. Haven't tested the encoder that much yet.


>> 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.

This an fixing anonymous access so that people could submit patches.  
Another week of SourceForge downtime and I am going to suggest moving  
the 1.2 repo to Apache (without package name conversion of course).

Andrus

Re: reverse engineering a postgresql database: no relationships detected?

[Tomi NA <he...@gmail.com>]

On 4/29/06, Andrus Adamchik <an...@objectstyle.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

Re: reverse engineering a postgresql database: no relationships detected?

[Andrus Adamchik <an...@objectstyle.org>]

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

Re: reverse engineering a postgresql database: no relationships detected?

[Tomi NA <he...@gmail.com>]

On 4/9/06, Cris Daniluk <cr...@gmail.com> wrote:
> I think the fix was in before M12 came out, but you should try the beta just
> to make sure, for obvious reasons. If you are still having trouble, I'm
> going to need you to create a DataMap that reproduces the problem, as the
> test cases that I was working with failed before the patch and pass after.

This is probably a long forgotten topic, but I'd rather close it than let it be.

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).
- 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.
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?

Tomislav

Re: reverse engineering a postgresql database: no relationships detected?

[Cris Daniluk <cr...@gmail.com>]

I think the fix was in before M12 came out, but you should try the beta just
to make sure, for obvious reasons. If you are still having trouble, I'm
going to need you to create a DataMap that reproduces the problem, as the
test cases that I was working with failed before the patch and pass after.

Cris

On 4/8/06, Tomi NA <he...@gmail.com> wrote:
>
> On 3/14/06, Cris Daniluk <cr...@gmail.com> wrote:
> >
> > Can you give the latest CVS a try before I mark this resolved? I added a
> > "second pass" that should catch skipped relationships.
> >
>
> I'm using 1.2M12 (March 23rd) and I have the same issue I started with.
> I've added a couple of fields as well as their respective foreign key
> constraints, tried to reengineer just that one table and got no
> relationships at all. I've just tried to reengineer overwriting everything
> in the existing model and got a relationless model.
>
> Has this been taken care of in 1.2B1?
>
> t.n.a.
>
>