This website uses cookies for visitor traffic analysis. By using the website, you agree with storing the cookies on your computer.More information

JVx 0.9 - release date fixed

The next Release of JVx has the version number 0.9 and will be published on 1st April.

This version is a big milestone for us because it contains all features which were planned for version 1.0, when we started the development of JVx. In the last two years, some requirements have changed, we got a lot of feedback and therefore we changed our initial feature list.

We are very happy with the quality of the last beta releases of 0.9.

A big "THANK YOU" to all JVx developers!

The release 0.9 contains a lot of new features and database operations are significant faster than before. We made a lot of UI optimizations and fixed some design issues. Our persistence API is prepared for case sensitive databases and your UI is not affected from case sensitive changes! With server-side triggers (not DB triggers) it is very easy to move business logic from your client or database tier to your server tier - perfect separation of layers!

Our roadmap for 0.9 contained about 100 Tickets and be sure, JVx 0.9 rocks the world!

JVx 0.9 design decission

In the last days we talked a lot about JVx's DB independency, because every DB has its own peculiarities.
Specifically the case sensitive is everywhere handled different. An Oracle DB prefers upper case column names, table names, ... A PostgreSql DB prefers lower case. It is possible to use quoting with JVx and everything works fine until you switch your database.


We develop an application with an Oracle DB. We don't use quoting because we know everything is upper case. Our client code contains column acces like that:


Now we have to switch from Oracle to PostgreSql (company decission). Because PostgreSQL prefers lower case column names, table names - we get a problem with our client because the column access is upper case. We could create our database objects in upper case and enable quoting for our DBAccess but that is all a lot of work and maybe our existing PostgreSql DB has objects which are case sensitive. We won't change our existing database objects!

It is an option that you change your application code when you change your database, but that is not a real solution - isnt it?

Because we think, things sould be easier with JVx, we decided to change the column access. With the final release of JVx 0.9 you have to access all columns with upper case letters. The mapping is handled from JVx. Because of this change, a JVx application (>= 0.9) will be DB independent.

What does this mean for JVx applications (< 0.9) ?

You need to change all column access to upper case letters where the access is not with upper case letters. That means, you need to check your client code and your server-side triggers.

Backwards compatibility?

It is possible to make it backwards compatible but it is very important to keep JVx simple and one of our first decissions was, that we don't put a lot effort into backwards compatibility before JVx 1.0. Things change after JVx 1.0 ;-)