Try it. And catch it, finally.

In my last project I ran into an “actually” quite obvious trouble I want to resolve properly once and for all times, because I expect it to be a regular requirement when working with something like JPA/Hibernate persistence layer and something like the Spring Framework Bean Instantiation mechanism.

When I persist some JPA mapped Entity into my database, I’d later on very much like to be able to recover it exactly in the state when it was persisted. This is what persistence is all about anyway, isn’t it? It is, but troubles arise when this persisted Entity originally was instantiated based on some Spring Prototype Bean Configuration. Typically, Parts of the Properties of such a prepopulated Beans are just for Configuration Purposes and to persist those Properties to the Database is either obsolete and causing a lot of redundant and performance burdening data (in case of e.g. simple configuration values or beans), but can also turn out to be difficult or impossible to achieve in case the injected Data (e.g. some Configuration carrying Singleton Bean) is just not made to be persistent.

However, later on, when recovering such an Entity from the Database it will have lost all it (non-persistent) configuration data. Of course: JPA/Hibernate constructs the Java Objects via the Default Constructor of the Class and populates it with the Property Values persisted in the Database. That’s it, basically. The solution for my issue should be easy and some instructions and/or even ready code should be obtainable via the Internet: I just have to “teach” Hibernate to construct the Java Objects derived as Database Entities not via the default Class Constructur but via the Spring Bean Instantiation. I “just” have to do some research about this…

Once having this in place, I expect such an approach to turn out to make very good sense for almost all persistent Entities, also for the simple cases, because it allows

• To externalize the configuration of transient-only Property values with default (prepopulated) values becoming persistent later on and to have all this transparent in one place within the Spring Prototype Bean Configuration.
• Domain specific Object Models to carry some (e.g. DAO aware) lookup or logic methods in case applicable and useful.

I’m eager to see it working soon!

(This post is part of my thoughts about A portfolio for Enterprise Web Applications)

When developing Database centric Applications you regularly stumble upon the “actually stupid” trouble that the User naturally wants to sort Data Tables presented to him “by every column available”. And the sort order should of course be the “naturally expected one”. Actually not a big deal? Sure not, however some troubles will unavoidably come along your road if you don’t take care of all the typical involved scenarios in advance (meaning: when designing the application).

Basically these issues boil down to the fact that something in a table column is presented to the user that is somehow different to what is directly stored in the underlying database. Typically

• Some key value is stored in the database, but on the UI the key is replaced with some display string. The User wants to see the Column sorted by Display Strings not by the underlying Keys.
• Some default language value is stored in the database, but for display the string is presented in some other language selected by the User. The User wants to see the column sorted in the displayed language not in some other one.
• A numeric value is for some reason (eventually for no wise reason…) stored in a string typed column of the database. The User wants to see such columns sorted numerically (and not “alphabetically”, meaning here sorted by the Character Codes of the displayed Numbers).
• A numeric value is somehow a systematic part of strings stored in a column of the underlying database, like in a column called “Reference”, holding values like “Issue #13, Page 24″. The User wants to see the mentioned Reference showing up after “Issue #2, Page 30″ and before “Issue #13, Page 101″. Unfortunately, when sorting “alphabetically”, it will show up exactly the other way round: after “Issue #13, Page 101″ and before “Issue #2, Page 30″…
• A column displays a string concatenated of several (arbitrarily typed) columns, eventually mixed with some fixed strings, like in “Maier Alfred, Austria, born Feb. 19, 1958″. The User wants to see such a Mr. Maier sorted before this other Austrian Mr. Alfred Maier born in December 1981, “of course”. Will he? Well, it probably depends on how all this stuff is implemented…

In order to be able to sort all this stuff in a consistent, performing (database centric) way and in a way the user will naturally expect it to be, we will need an equally consistent and problem aware approach for

• Maintaining, loading and storing I18n aware display labels in the database.
• Taking care of numerical characters stored inside string typed database columns.
• Systematically generating concatenated Columns consisting of the contents of several database columns.
• Internally representing Data Tables aware of the Database Sort Column(s) for each Display Column.

Yep, I’d definitely like to spend some more thoughts on such a consistent approach and develop everything needed (and not yet available) in code.

(This post is part of my thoughts about A portfolio for Enterprise Web Applications)

Connected to my thoughts about A portfolio for Enterprise Web Applications I am thinking about developing (= providing a well tested, bundled and documented software feature with minimal coding effort) a mechanism which is capable of the following

• Log all persisted states of an Entity inside the Database – always including Information about Action Type, Time and User/Process
• Allow also forthcoming states to be saved as such an “inactive” Entity state (meaning “to be activated later”).
• Allow for Action Types the Database Operations (C)reate, (R)ead, (U)pdate, (D)elete *and* (A)ctivate (the right to activate a Database changing Operation) to be defined as Rights a User/Process may have on a Class of Entities.
• Allow each such User Right on an Entity Class to be restricted by a (custom) Right Condition.
• Provide Out of The Box a Right Condition allowing a User to (A)ctivate only if the Operation to be activated was not done by the activating User himself (”Second Set of Eyes” Feature)
• Allow for Ability to activate not just forthcoming, but also every old “inactive” Entity State. (”Entity Rollback” Feature)

I want to do this based on Java while making use of JPA/Hibernate simply because these ideas are about leveraging preexisting project experience and knowledge. To be further investigated is the Usage of

• Hibernate Interceptors for Logging Entity State change
• Hibernate XML API also for Logging
• (Hibernate) Bean Validator Framework for CRUD and Activation Rights and mentioned Custom Conditions