While the last post introduced j2flex and the big picture behind it, this article will take a look at core features of the framework. We start with some theory first as this is needed to understand the sample code later on.

The main concept in j2flex is something called a “meta database”, an object-oriented data model stored in a relational database system like MS SQL Server or Oracle. So, how does this compare to a “traditional” approach? For example, imagine you want to build a CRM application with Organizations and Contacts. From a data model point of view a Contact typically stores information like a name, an email address and a birth date. In a traditional database you would probably create a table “contact” with columns like NAME of type VARCHAR and BIRTHDATE of type DATE and so on. The identity (primary key) of the Contact could be an INTEGER and so on. In an object-oriented data model you would not persist everything in one single table but store the different data values in different tables and every table is made to store data of a certain type only. In the above case the NAME and EMAIL columns would be stored in the OBJ_TEXT table (a table which only stores VARCHAR data) and the BIRTHDATE data would get stored in the OBJ_DATE table and so on. So every row in every table only stores single aspects of a whole object. Of course, to re-assemble an object, we need a unique key again. In the world of j2flex every object stores an OBJ_ID and an OBJ_TYPE value. Both of the are numeric and together they a unique primary key to lookup date from the several tables.

This approach allows us to persist pretty complex data definitions very easily and without much hassle, including 1-1, 1-n and n-m relationships. Due to this dynamic persistance schema, new object types (i.e. business entities) can be added to the system pretty easily without modifying the physical database model. Also, it’s super-easy to modify existing object definitions. On the other hand, if you already have a full-blown physical database model in place, it’s quite easy to make it work with j2flex. All you have to do is to add OBJ_ID and OBJ_TYPE columns to your physical data model.

Now that you know how data gets persisted in j2flex the next question is what to use to query this “meta database”? Well, SQL of course! Probably the best thing in j2flex’ core engine is the SQL Parser. This allows you to use pseudo-SQL statements to query the database. Why pseudo? Because it is no “real” SQL. The SQL you send to j2flex is parsed on the server side into real SQL before the data is fetched from the database. Why’s that? As said above, when a Contact gets persisted, the real data gets stored in several physical tables. The SQL Parser allows you to query the database as if the Contacts would be stored in a table called CONTACT- This is because when you create a new data type “Contact” a virtual table of that name gets created, think of it as the class name in terms of OOP. So querying all Contacts becomes as simple as

select * from CONTACT

Doesn’t sound too complicated, does it? The neat thing is that with j2flex you can send those queries directly from a Flex client to the server. As they are no real SQL queries there’s no danger of SQL injections as everything gets handled by the SQL Parser. Also, the SQL Parser only allows SELECT statements, so you cannot call INSERT/UPDATE/DELETE on it. To create, update or delete objects (data) you use a special API which we will see in the next article.