wiki:FmgVen/Development/Implementation

Version 7 (modified by fmguler, 14 years ago) (diff)

added list to 10.02.2011 item

fmgVen Implementation Notes

This page defines the final state of the current implementation of the project. This page should be updated after milestones. Until then, weekly (or periodically) the updates are recorded to separate pages/sections.

fmgVen 0.2 Milestone

  • 20.07.2010: [22] [23] Started to work on fmgVen 0.2. Arranged project license as apache 2.0 and created new package hierarchy. The aim is to translate all code to English and transform considering the new requirements.
  • 23.09.2010: [24] In order to test with the database easily, added support for database versioning (liquibase). Database setup and rollback can be used in test classes. (i.e. the database status is resetted before testing)
  • 04.10.2010: [25] Added test scenarios and the Use Cases wiki page. This will help to concentrate on what the output of the tool will look like. It is the spec. There exists a unit test for each use case scenario.
  • 17.10.2010: Started implementing Ven.save(). Converted old code to be built with JDK 1.4. In fact, it turned out to be very easy. Old Ven can also run at 1.4. Did not commit the save work since it is not finished yet.
  • 27.10.2010: [26] Ven.save() is almost complete. Updated assigning new object id related sections, divided them into private methods. It's much more elegant now. At 29th, an important decision is made. Database primary key fields used to be named "no", but the whole world uses "id" instead. If this tool targets a wider audience than just me and a few fellas, it would be more sane to name it conventionally, as the aim of the tool is "convention over configuration ORM".
  • 16.01.2011: [27] Ven.delete() is completed. Added missing javadoc comments.
  • 10.02.2011: [28] [29] Ven.get() and Ven.list() are completed. This is a significant part of the system. Associations (joins/includes) are handled. I am only unsure about handling the one to many reverse join field. There is not an easy way to infer it from the classes. We just need to know which field refers to the parent object. The element class in the list can be inferred somehow. The only place requiring configuration is here. Of course there can be some kind of convention if there is only single association.