[
https://issues.apache.org/jira/browse/CAY-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14113623#comment-14113623
]
ASF GitHub Bot commented on CAY-1946:
-------------------------------------
GitHub user AlexKolonitsky opened a pull request:
https://github.com/apache/cayenne/pull/6
CAY-1946 CDbimport improvements
Maven changes
1) jacoco report to control code coverage, it was included into
"tests-development" profile
2) new dependency datafactory - in order to use random data in tests where
exact value not really important
3) XmlUnit - for xml file comparison
Small refactoring
1) remove 'final' in loop parameters and private methods
2) remove public in interfaces
3) remove unnecessary casting
4) add {} for if operator
5) add @Deprecated for methods which marked as deprecated in comments
6) replace StringBuilder with simple string concatenation; since java 5
compiler can do this optimization by it self:
http://docs.oracle.com/javase/specs/jls/se5.0/html/expressions.html#15.18.1.2
7) add more info into exceptions
8) move methods into class where it give most cohesion
9) make object fields final where it is possible
Other changes
1) added DbLoaderConfiguration class; this class responsibility should be
provide to DataLoader all necessary information
2) added DefaultDbLoaderDelegate to avoid all methods implementation where
only one required
3) make token name a constructor parameter and remove all other
implementations of this method
4) I've created builders for domain objects (i.e. DataMap, Db\Obj Entity,
Db\Obj Attribute, ...) and Factory for all builders; Main goal to provide easy
way of construction objects and fill them partially with only data that
necessary for test case, everything else required to make object valid will be
generated randomly.
5) DbMergerTest - test correct identification of DbToModel changes
6) TokensReversTest - test compliance with the invariant
token.reverse.reverse == token
7) TokensToModelExecution - test application correctness of DbToModel tokens
8) DbImportAction - this class will check availability of dataMap file and
do merge if it is exist otherwise just load model from db
9) DbImportParameters - was renamed to DbImportConfiguration and also
responsible fo construction of necessary objects for during import process
10) functional or end-to-end test for maven plugin basic usage scenarios
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/AlexKolonitsky/cayenne
CAY-1946_CDbimport_improvements
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cayenne/pull/6.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #6
----
commit 90de78de01b25c2d62bfe7e431e10aa12cb07d15
Author: alexkolonitsky <alex.kolonit...@gmail.com>
Date: 2014-08-18T11:18:54Z
CAY-1942 Refactoring of NamedObjectFactory and NamingStrategy
* Change enums first letter to lower case
* Rename SmartNameGenerator to DefaultNameGenerator; BasicNameGenerator to
LegacyNamegenerator,
commit 98b4c81198931a8f55b182b0b74cdbe2a43b8540
Author: alexkolonitsky <alex.kolonit...@gmail.com>
Date: 2014-08-28T09:47:39Z
CAY-1946 CDbimport improvements
Maven changes
1) jacoco report to control code coverage, it was included into
"tests-development" profile
2) new dependency datafactory - in order to use random data in tests where
exact value not really important
3) XmlUnit - for xml file comparison
Small refactoring
1) remove 'final' in loop parameters and private methods
2) remove public in interfaces
3) remove unnecessary casting
4) add {} for if operator
5) add @Deprecated for methods which marked as deprecated in comments
6) replace StringBuilder with simple string concatenation; since java 5
compiler can do this optimization by it self:
http://docs.oracle.com/javase/specs/jls/se5.0/html/expressions.html#15.18.1.2
7) add more info into exceptions
8) move methods into class where it give most cohesion
9) make object fields final where it is possible
Other changes
1) added DbLoaderConfiguration class; this class responsibility should be
provide to DataLoader all necessary information
2) added DefaultDbLoaderDelegate to avoid all methods implementation where
only one required
3) make token name a constructor parameter and remove all other
implementations of this method
4) I've created builders for domain objects (i.e. DataMap, Db\Obj Entity,
Db\Obj Attribute, ...) and Factory for all builders; Main goal to provide easy
way of construction objects and fill them partially with only data that
necessary for test case, everything else required to make object valid will be
generated randomly.
5) DbMergerTest - test correct identification of DbToModel changes
6) TokensReversTest - test compliance with the invariant
token.reverse.reverse == token
7) TokensToModelExecution - test application correctness of DbToModel tokens
8) DbImportAction - this class will check availability of dataMap file and
do merge if it is exist otherwise just load model from db
9) DbImportParameters - was renamed to DbImportConfiguration and also
responsible fo construction of necessary objects for during import process
10) functional or end-to-end test for maven plugin basic usage scenarios
----
> CDbimport improvements
> ----------------------
>
> Key: CAY-1946
> URL: https://issues.apache.org/jira/browse/CAY-1946
> Project: Cayenne
> Issue Type: Improvement
> Components: Non-GUI Tools
> Reporter: Alex Kolonitsky
>
> We’ve experimented with automated db-first approach to Cayenne modeling for
> more than a year on a set of client projects. Roughly this approach means
> that DB evolution is managed via external tools (e.g. liquibase) and Cayenne
> artifacts are managed using the following POM configuration:
> <plugin>
> <groupId>org.apache.cayenne.plugins</groupId>
> <artifactId>maven-cayenne-plugin</artifactId>
> <configuration>
> ...
> </configuration>
> <executions>
> <execution>
> <id>default-cli</id>
> <goals>
> <goal>cdbimport</goal>
> <goal>cgen</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> “cdbimport” ensures that Cayenne model is always in sync with DB, “cgen” -
> that Java classes are in sync with the model. There are zero problems with
> “cgen", not so with “cdbimport". If you control the schema, you get a
> decently named Java classes/properties in 95% of the cases. Here we are
> trying to address the remaining 5% that make things ugly:
> * Inability to generate meaningful relationship names in many cases.
> * Inability to customize attribute/relationship names and data types.
> To solve this here we are proposing a merge algorithm that would preserve
> customizations to the Obj* layer made by the user. And in addition to that a
> special descriptor that can be used for more advanced filtering and
> customization of cdbimport process. Both of these improvements will hopefully
> result in “cdbimport” becoming a tool of choice for Cayenne work for many
> users.
> https://docs.google.com/document/d/1DF5-_mMDCuH7iUFhEFDm2q-ebVeSPgvOaymho88ywJ0/edit?pli=1
--
This message was sent by Atlassian JIRA
(v6.2#6252)
