fmgVen - create a new package hierachy to be used for new development and translate old code

[fmguler]

The ancient fmgVen tool is planned to be updated. It uses non existing net.fmg package hierachy, and all of the code including comments are in Turkish. While it had been intentionally and meticulously done so, for mainstream use it needs to be in English to reach a wider target audience. Also it contradicts with coding conventions of most projects in the original form, mixed languages, no getters (since Turkish is a agglutinative language.

I appreciate the idealistic endeavor however, past me. The original code will forever rest in peace in the code repository.

[fmguler]

In [22]:

Refs #3 - The new com.fmguler.ven package is created. Project netbeans encoding is changed from windows 1254 to UTF-8. Existing Turkish source files are transformed to UTF-8. Project license is set as apache 2.0 and netbeans license template is created (which is copied from netbeans apache20 and project name is added). To install this template to netbeans, you should import the etc/license/license-ven-apache20.txt to netbeans->tools->templates ->licenses.

The new Ven class is created having the new license template. Now the translation task is to be done.

[fmguler]

In [23]:

Refs #3 - Spring 2.5 libraries are added. Old spring 2 jar is removed. The main dependency is spring-jdbc.jar and spring-beans.jar, spring-core.jar and spring-tx.jar are referenced from them. For testing with postgresql, its driver is added.

The interface is translated to the new Ven class. Instead of adding 'object' to all of the methods, I aimed to make it less verbose, so just shortened the name of the methods to list, get save, delete.

Lastly, we have a class to demonstrate the usage called 'Sample' in the test packages.

[fmguler]

After updating fmgVen wiki according to infrastructure ​wiki template, I am starting to work on this ticket, seriously.

[fmguler]

In [24]:

Refs #3 - Added liquibase library for test database operations, which means we can update and rollback a test database in the test scenarios. Now we should add test scenarios to be tested on this database.

[fmguler]

In [25]:

Refs #3 - Started adding test scenarios. These are in line with the use cases: ​http://trac.fmguler.com/UtilityProjects/wiki/FmgVen/Development/UseCases

[fmguler]

In [26]:

Refs #3 - Ven.save() is transferred to the new package. Save use case is completed. Convert.toDB() converts camel case object names to database names with underscores. Unchecked VenException is thrown by Ven methods. Liquibase changelog (test-db-changelog.xml) is changed to include only a simple object to test save operation. It creates a sample database table and inserts a sample row. On rollback it removes sample data. Using liquibase, Sample.java builds database, tests save operation and rolls back.

QueryGenerator generates insert and update queries for save and generates sequence query to assign ids to new objects. Ven calls query generator and runs the query using spring jdbc template.

Old codebase updated to run at Java 1.4

[fmguler]

In [27]:

Refs #3 - Ven.delete() is converted to the new format. Missing javadocs are entered.

[fmguler]

In [28]:

Refs #3 - Ven.get() is converted to the new format. QueryGenerator and QueryMapper are mostly OK, generateRecursively and mapRecursively are converted and checked. Handles joins (includes/associations) many to one and one to many. For one to many, the reverse join field can be determined in a couple of ways. First way is (prefereed) having VenList as the list implementation which specifies the element class and the join field. Second way is using Java 1.5 generic type to detect element class (not yet implemented) and guessing join field by convention (if multiple joins exist, this won't work). The last way is to have some kind of annotation or configuration, which is of course the least preferred way. VenList has a static method to determine the element class in the object list, which currently calls getElementClass if the list is an instance of VenList. In the future other options can be implemented.

Getting object using joins (includes/associations) are tested using dummy assocations between SomeDomainObject and AnotherDomainObject. The Sample class builds the database, tests the operations and rolls back to the initial state. Database refactoring operations are moved to the LiquibaseUtil for clarity.

In the future, the generated queries will be shortened using hashed aliases, and the criteria subsystem will be implemented.

[fmguler]

In [29]:

Refs #3 - Ven.list() is converted to the new format. Almost the same as Ven.get(). Added javadoc to Ven public methods. Added listing test, and made the sample domain object toString methods more readable.

Now, adding the criteria parameter to the operations is to be done.

[fmguler]

In [30]:

Fixes #3 - Criteria object is mostly implemented. An override of Ven.list() having criteria parameter is added. Old codebase only had string based criteria. In this commit, I am also adding typed criteria as a new feauture. With this new criteria system, user can create criteria object like;

new Criteria().eq(attr,value).like(attr,value).and().gt(attr, value).or().orderAsc(attr).orderDesc(attr).limit(limit, offset);

The orderings and the limit/offset values are not taken into account in the Ven (these are trivial, I will do them later).

Not thouroughly tested, because complex scenarios are only possible when applying to a real problem in a real application (which I am planning to do next).