cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: reverse engineering refactoring
Date Wed, 05 Oct 2016 06:24:05 GMT
Hi Tony,

> 1) have the model "remember" which datasource was used to
> Rev-engineer.  

Good point. Not sure if you are looking at M3 or M4 (this problem exists on both IIRC). In
M4 reverse engineering UI has been changed completely. And we will still be reworking that
version to make it more "production quality".


> 2 it would be nice if the graph layouts for the data models actually used some kind of
layout algorithm to prevent the tables from being the mess that they are..

That's like the most requested feature, yet there are no developers working on the graph layout
at the moment. Would be nice if someone could take ownership of this component and address
all the issues.

> Two suggestions and I'd be willing to help on any of this.

Much appreciated.

Andrus


> On Oct 5, 2016, at 3:51 AM, Gmail <tgiaccone@gmail.com> wrote:
> 
> Two suggestions and I'd be willing to help on any of this.
> 
> 
> 1) have the model "remember" which datasource was used to
> Rev-engineer.  
> 
> 2 it would be nice if the graph layouts for the data models actually used some kind of
layout algorithm to prevent the tables from being the mess that they are..
> 
> Tony Giaccone
> 
>> On Oct 3, 2016, at 2:57 PM, Andrus Adamchik <andrus@objectstyle.org> wrote:
>> 
>> You've probably seen tons of semi-random commits from me lately :)
>> 
>> What I was trying to do is to bring some sanity into reverse-engineering and its
plethora of configurations, settings, strategies and flows. I am still not fully finished,
but some important steps are already complete:
>> 
>> * Code related to reverse engineering backend was split from cayenne-server into
its own "cayenne-dbsync" module.
>> 
>> * The most challenging part of was moving MergerTokenFactory, as factories are adapter-specific.
I came up with a few DI tricks to preserve per-adapter implementations. Long story short -
"merge" package is now in "cayenne-dbsync" as well.
>> 
>> * Name generators for various model objects in various contexts were unified, heavily
refactored and placed in "cayenne-dbsync" as well. There are just 2 visible ones: NameBuilder
and ObjectNameGenerator. Both complement each other and are fairly easy to understand.
>> 
>> * Removed most logic forks in our reverse engineering flow. Now regardless of whether
you do rev-eng from scratch, or merging into an existing DataMap, the sequence is pretty much
the same:
>> 
>> 1. DbLoader reverse engineers the DB based on its filters into a temporary DataMap.
>> 2. This DataMap contains only the DB layer. No ObjEntities.
>> 3. Then we compare this DataMap with our target DataMap, generate MergerTokens and
merge them.
>> 
>> Now of the above is backwards compatible API-wise, but this is not the core API that
we absolutely need to preserve between releases. So I think this is not a problem. The only
visible incompatibility for an average user is this:
>> 
>> https://issues.apache.org/jira/browse/CAY-2118
>> 
>> Next I am going to pull some stuff from downstream cayenne-tools into cayenne-datasync
to make reverse engineering mechanism fully agnostic of the caller. There's probably more
cleanup to do around configurations, etc.
>> 
>> After that going to finally fix a few rev-eng bugs that triggered this whole endeavor.
>> 
>> Also we'll need to spend some time on the new rev-eng tab in the modeler. It kinda
works, but there are UI quirks, and simply lots of unused potential in how we can present
the new backend capabilities via the UI.
>> 
>> Hope all this make sense :)
>> 
>> Andrus


Mime
View raw message