Try it. And catch it, finally.

While still in the middle of taking care of my momentarily sick little girls, I will today continue the reflections about the lifecycle of data and go through a sample of temporal data to further illustrate what I am speaking about. Bitemporality: this e.g. is how Martin Fowler (Patterns for things that change with time) describes the two time dimensions of Bitemporal Objects:

I think of the first dimension as actual time: the time something happened. The second dimension is record time, the time we knew about it. Whenever something happens, there are always these two times that come with it.

Foto credits to bobydimitrov according Creative Commons BY-SA 2.0

“Whenever something happens, there are always these two times that come with it.”: the information that something happened itself needs time until it reaches its recipients and maybe even more time until it is recorded in some database… and this of course does not just concern a lightning and the subsequent reception of the thunder within some miles, it does not just concern the recording of the lightnings in some weather forecasters database or the reader of a local newspaper covering this thunderstorm. It concerns every single profane fact of life.

Tracking Record Time

Let’s therefore focus on such a profane fact of life and investigate the relationship between a hotel room and it’s price. Let’s imagine a simplified Price Watcher Application tracking the Prices of the rooms of several hotels in a given city:

A better normalised real life database schema for such an application would of course look a bit different, but this should not bother us at the moment: with this simple table we can already answer the question “Where do I get the cheapest city hotel room at the moment?” sorting the table by price in descending order… but actually… can we answer this? To be slightly more precise – and we have to be precise for our topic – we can just answer the question “Where do we get to our current knowledge the cheapest city hotel room at the moment?”. After all, we don’t reflect reality here, we just reflect what we know about it…

If our Price Watcher App eventually becomes a relevant factor in the market, conflicts with hotel owners could occur more frequently (”Why do you update just my price cuttings so slowly?”). We therefore might want to add the information when exactly the specific price was recorded with us:

But thinking about this twice, wouldn’t it be wise not just to remember when we updated the price the last time, but to remember many such updates in order to be able to discuss single cases and to proove that we honestly treat all hotels equally? Well, then we may not update the table anymore but instead insert a new row whenever a price change occurs. Let’s for this purpose focus on “Bedtime Lodge” from here on:

Now, let’s back-pedal at this point a little bit by “denormalising” the information we already have here: we add another column, which serves to reflect until which point in time we considered the associated information to be valid: it is the moment when the price for one hotel changed and we therefore added a new row:

We realize: the new “Effective until” information is “unlimited” for new rows. And it is equal to the “Recorded At” Column of the new Row, the moment we “update” it by inserting a new row. Now: whenever we ask for current prices, we will want to filter out all the rows with outdated effectivity. But actually we should generalize this filtering procedure a bit: whenever we ask this table for a consistent set of data given at the current or a historic date, we always filter out rows for which this date is not in between “Recorded at” and “Effective until”. In order to make this even easier, we could decide to replace the “unlimited” with a date far enough in the future in order not to cause any Y2K problematic during our lifetime:

And by the way, watching this: wouldn’t it be nice to show to our users not just the current price, but also things like e.g. how the minimum room price for a given hotel developed in the past or which hotels frequently offer rooms for minimum prices? All the information we need for this already is in place! We would just have to think about the queries a little bit.

Tracking Actual Time

Now, question: what’s bitemporal about this data. Answer: so far, nothing. So far, we just cared about Record Time, meaning we just cared about the moment we learned about a price change, we did not care so much about when it actually happened. If we call this type of storing data “Record Temporal”, we can imagine that we can use a very similar mechanism to store “Actual Temporal” Data by changing the semantics of our two Time Columns and call them now Actual From and Actual Until:

What changes when giving the columns the semantics of Actual Time compared to Record Time? Well, when it comes to Record Time, it’s always an easily retrievable System Time we deal with: the moment some data is inserted/updated, we change the “Effective until” of the old row and the “Recorded at” of the new row to the current System Time and are finished. When it comes to Actual Time, things are different. Typically this point in time can just be provided by the human (or external system) using the database application. He/she/it is the only one who can tell: wait, now we update the information in your database, right, but actually the change in the real world already happened earlier. Which is why we have to ask ourselves, whether this kind of semantics would add value to our Price Watcher App? Probably not. But: the moment we change perspective on the given sample we find that somebody else will be interested in both Times: the “Bedtime Lodge”.

Bitemporality

The “Bedtime Lodge” will also have to maintain a room and price database with similar contents but just for their own rooms. The goal is now not to “watch” prices, but actually to “define” and “maintain” them. Of course, we don’t need the “Hotel” column anymore, because we definitely know, it’s us:

The requirement we face here is to be able to define and maintain Prices which come into effect somewhen in the future. My next post will therefore combine the Concepts of Record Time and Actual Time and complete the sample showing the full Bitemporality.

Some time ago I wrote a requirements oriented post about controlling the lifecycle of persisted entities.

Today I want to step back a bit and start writing about a number of “temporal” issues and problems of business applications development. On my way of thinking about this stuff I want to discuss, develop and improve (one or more?) possible solutions for them. This rankles me since a longer time: it’s the kind of stuff that regularly nobody has time (sic!) to care about when a business application project starts and which (again: regularly) begins to hurt and cost (maybe lots of) time and money later on when the true business requirements are discovered. And regularly they are discovered piece by piece only.

Foto credits to monkeyc.net according Creative Commons BY-NC-SA 2.0

So, what do I mean with Lifecycle of Data? At some point in time our baby-data is born. Then, while growing-up and aging it keeps some properties while others will change with time. Until at some point later it will die and disappear from this world. When we compare this picture of life with the basic data manipulation mechanisms a typical database management system provides we find a similar pattern: at some point in time a new record is INSERTed into a database table. Then, when time goes by, some of it’s properties (columns) will be UPDATEd. Until at some point later somebody decides to DELETE it from the database and therefore remove all it’s tracks from this world.

Let’s investigate this simple fact of what’s actually happening here a little bit deeper by reconnecting the lifecycle of information about the world with the lifecycle of the data living in the database. Databases regularly don’t store arbitrary data, but try to reflect some aspects of the real world. As a sample, I suggest to think of a civil registry’s database storing the spouses, children and all their places of living for a certain countries citizens. Let’s e.g. focus on one of those persons – let’s call her Mrs. Sometimes – and her place of living: some (probably short) time after her birth this fact of birth will be reflected in the database by INSERTing information about herself and INSERTing her first place of living. Later on, Mrs Sometime’s place of living will potentially change several times. Maintaining this databases address table therefore means to try best to reflect the real status of this single aspect of the world: where do my fellow citizens actually live? If somebody moves we UPDATE, if somebody dies, we DELETE.

To sum it up until here:

The basic data manipulation operations provided by a typical relational database management system (INSERT, UPDATE, DELETE) reflect the natural lifecycle of the recorded aspects of the (ever changing) outside world. The database we maintain by applying those operations tries it’s best to reflect the current status of the outside world. But regularly, it will take some time until the information finds its way into the database. And sometimes this will never happen – and the data inside the database will for some reason be plain wrong, meaning: not correctly reflecting the true facts of the outside world.

I used some important terms in the last paragraph which will propably occupy me for a longer time: I said the database reflects the current status (because outdated information is UPDATEd or DELETEd). I also said there typically is a time gap between a status change in the outside world (e.g. somebody moves) and the status change in the database (here e.g. correctly reflecting this move). And I said some database data may be wrong data.

To finish this post I want to deduct from this some of the typical user questions our simple-sample-database cannot answer:

• Where did Mrs. Sometimes live five years ago?
• When did Mrs. Sometimes move the last time?
• From when on did the Database reflect this fact?
• What did we know about Mrs. Sometimes’s first place of living some weeks after her birth?
• And what do we know about it today? When was it discovered that the original information about Mrs Sometimes’s first place of living was manipulated by her father and therefore corrected later on?
• And where can we write down the fact that Mrs’ Sometimes just called us and told us that she will definitely move in two month and already wants to drop this information?

Unfortunately the necessity to ask such questions, such “use cases” are not uncommon at all. In fact they are strongly typical and appear in many flavours. But they are typically not thought of from the beginning of an average application development on. To be continued.

This is the simple and at the same time bold promise of Googles Web Toolkit (GWT) on it’s relatively decent web housing on Google Code:

Developers can spend 90% of their time working around browser quirks. In addition, building, reusing, and maintaining large JavaScript code bases and AJAX components can be difficult and fragile. Google Web Toolkit (GWT), especially when combined with the Google Plugin for Eclipse, eases this burden by allowing developers to quickly build and maintain complex yet highly performant JavaScript front-end applications in the Java programming language.

As a first step of my personal convergence to this technology, I want to play through the official “StockWatcher” Getting Started Tutorial at their Website. I’m really curious, what I will like and what I maybe won’t like at all, especially when comparing my then freshly developed GWT awareness with the still cloudy but at the same time already demanding requirements I have in my mind with respect to Best-Of-Breed UI Technologies.

I don’t want to use Eclipse as suggested and recommended overthere, but IntelliJ IDEA, so maybe I can even deliver some additional value compared to the “official” tutorial. As Information about IDEAs GWT Support I found their 1-2-3 Video GWT Tutorial.

Step 1: Creating a GWT Project (Please see the Official Tutorial, too.)

1. Install Google Web Toolkit
2. Right Click on your IntelliJ IDEA Java Project.
3. Select ‘Add Framework Support…’
4. Check ‘Google Web Toolkit’ and select proper Installation Path
5. Create a Java Package called ‘com.google.gwt.sample.stockwatcher’
6. Right click your Package, select ‘New…/Google Web Toolkit/GWT Module’ and enter ‘StockWatcher’ as Name.
7. Right click your Package, select ‘New…/Google Web Toolkit/GWT Remote Service’ and enter ‘Greeting’ as Name.
8. If you happen to use Mac OS X, you must edit the Project Settings to use a Java 1.5 runtime for GWT Hosted Mode.

Step 2: Designing the Application Please see the Official Tutorial

Step 3: Building the User Interface (Please see the Official Tutorial, too.)

1. Basically this Step consists of editing the StockWatcher Class (which means implementing an EntryPoint Interface):

   public class StockWatcher implements EntryPoint {
   
     private VerticalPanel mainPanel = new VerticalPanel();
     private FlexTable stocksFlexTable = new FlexTable();
     private HorizontalPanel addPanel = new HorizontalPanel();
     private TextBox newSymbolTextBox = new TextBox();
     private Button addStockButton = new Button("Add");
     private Label lastUpdatedLabel = new Label();
   
     /**
      * Entry point method.
      */
     public void onModuleLoad() {
       // Create table for stock data.
       stocksFlexTable.setText(0, 0, "Symbol");
       stocksFlexTable.setText(0, 1, "Price");
       stocksFlexTable.setText(0, 2, "Change");
       stocksFlexTable.setText(0, 3, "Remove");
       // Assemble Add Stock panel.
       addPanel.add(newSymbolTextBox);
       addPanel.add(addStockButton);
       // Assemble Main panel.
       mainPanel.add(stocksFlexTable);
       mainPanel.add(addPanel);
       mainPanel.add(lastUpdatedLabel);
       // Associate the Main panel with the HTML host page.
       RootPanel.get("stockList").add(mainPanel);
       // Move cursor focus to the input box.
       newSymbolTextBox.setFocus(true);
     }
   
   }
   

2. Once you have this you can already startup your “hosted” Test UI by right-clicking your StockWatcher Class and selecting ‘Run StockWatcher’. Once your ‘Hosted Mode Browser’ is running, it will reflect any Code Change you make after a Click on its ‘Refresh’ Button.
3. One Remark: I had to increase my JRE heap size setting to 256MB first, by editing the Run/Edit Configurations (-Xmx256M) to get the Hosted Mode running.

Step 4: Managing Events on the Client Please see the Official Tutorial

Step 5: Coding Functionality on the Client Please see the Official Tutorial

Step 6: Managing Events on the Client (Please see the Official Tutorial, too.)

After having successfully added the EventListeners (Step 4), the required Table Coding (Step 5) and played through the quite convincing Debugging Section (Section 6), my Class looks now looks like the following:

public class StockWatcher implements EntryPoint {

    private VerticalPanel mainPanel = new VerticalPanel();
    private FlexTable stocksFlexTable = new FlexTable();
    private HorizontalPanel addPanel = new HorizontalPanel();
    private TextBox newSymbolTextBox = new TextBox();
    private Button addStockButton = new Button("Add");
    private Label lastUpdatedLabel = new Label();

    private static final int REFRESH_INTERVAL = 5000; // ms
    private ArrayList<String> stocks = new ArrayList<String>();

    public void onModuleLoad() {
        // Create table for stock data.
        stocksFlexTable.setText(0, 0, "Symbol");
        stocksFlexTable.setText(0, 1, "Price");
        stocksFlexTable.setText(0, 2, "Change");
        stocksFlexTable.setText(0, 3, "Remove");
        // Assemble Add Stock panel.
        addPanel.add(newSymbolTextBox);
        addPanel.add(addStockButton);
        // Assemble Main panel.
        mainPanel.add(stocksFlexTable);
        mainPanel.add(addPanel);
        mainPanel.add(lastUpdatedLabel);
        // Associate the Main panel with the HTML host page.
        RootPanel.get("stockList").add(mainPanel);
        // Move cursor focus to the input box.
        newSymbolTextBox.setFocus(true);
        // Setup timer to refresh list automatically.
         Timer refreshTimer = new Timer() {
           @Override
           public void run() {
             refreshWatchList();
           }
         };
         refreshTimer.scheduleRepeating(REFRESH_INTERVAL);
        // Listen for mouse events on the Add button.
        addStockButton.addClickHandler(new ClickHandler() {
            public void onClick(ClickEvent event) {
                addStock();
            }
        });
        // Listen for keyboard events in the input box.
        newSymbolTextBox.addKeyPressHandler(new KeyPressHandler() {
            public void onKeyPress(KeyPressEvent event) {
                switch (event.getCharCode()) {
                    case KeyCodes.KEY_ENTER: addStock();
                }
            }
        });
    }

    private void addStock() {
        final String symbol = newSymbolTextBox.getText()
            .toUpperCase().trim();
        newSymbolTextBox.setFocus(true);
        // Stock code must be between 1 and 10 chars that
           are numbers, letters, or dots.
        if (!symbol.matches("^[0-9A-Z\\.]{1,10}$")) {
            Window.alert("'" + symbol + "' is not a valid symbol.");
            newSymbolTextBox.selectAll();
            return;
        }
        newSymbolTextBox.setText("");
        // Don't add the stock if it's already in the table.
        if (stocks.contains(symbol))
          return;
        // Add the stock to the table.
        int row = stocksFlexTable.getRowCount();
        stocks.add(symbol);
        stocksFlexTable.setText(row, 0, symbol);
        // Add a button to remove this stock from the table.
        Button removeStockButton = new Button("x");
        removeStockButton.addClickHandler(new ClickHandler() {
            public void onClick(ClickEvent event) {
                int removedIndex = stocks.indexOf(symbol);
                stocks.remove(removedIndex);
                stocksFlexTable.removeRow(removedIndex + 1);
            }
        });
        stocksFlexTable.setWidget(row, 3, removeStockButton);
        // TODO Get the stock price.
        refreshWatchList();
    }

    private void refreshWatchList() {
        final double MAX_PRICE = 100.0; // $100.00
        final double MAX_PRICE_CHANGE = 0.02; // +/- 2%
        StockPrice[] prices = new StockPrice[stocks.size()];
        for (int i = 0; i < stocks.size(); i++) {
            double price = Random.nextDouble() * MAX_PRICE;
            double change = price * MAX_PRICE_CHANGE
                * (Random.nextDouble() * 2.0 - 1.0);
            prices[i] = new StockPrice(stocks.get(i), price, change);
        }
        updateTable(prices);
    }

    private void updateTable(StockPrice price) {
        // Make sure the stock is still in the stock table.
        if (!stocks.contains(price.getSymbol())) {
          return;
        }
        int row = stocks.indexOf(price.getSymbol()) + 1;
        // Format the data in the Price and Change fields.
        String priceText = NumberFormat.getFormat("#,##0.00")
            .format(price.getPrice());
        NumberFormat changeFormat = NumberFormat
            .getFormat("+#,##0.00;-#,##0.00");
        String changeText = changeFormat.format(price.getChange());
        String changePercentText = changeFormat
            .format(price.getChangePercent());
        // Populate the Price and Change fields with new data.
        stocksFlexTable.setText(row, 1, priceText);
        stocksFlexTable.setText(row, 2, changeText + " ("
            + changePercentText + "%)");
    }

    private void updateTable(StockPrice[] prices) {
        for (int i = 0; i < prices.length; i++) {
            updateTable(prices[i]);
        }
        // Display timestamp showing last refresh.
        lastUpdatedLabel.setText("Last update : " + DateTimeFormat
            .getMediumDateTimeFormat().format(new Date()));
    }

}

In addition to that I have some encapsulated functionality in a new StockPrice class:

public class StockPrice {

    private String symbol;
    private double price;
    private double change;

    public StockPrice() {
    }

    public StockPrice(String symbol, double price, double change) {
        this.symbol = symbol;
        this.price = price;
        this.change = change;
    }

    public String getSymbol() {
        return this.symbol;
    }

    public double getPrice() {
        return this.price;
    }

    public double getChange() {
        return this.change;
    }

    public double getChangePercent() {
        return 100.0 * this.change / this.price;
    }

    public void setSymbol(String symbol) {
        this.symbol = symbol;
    }

    public void setPrice(double price) {
        this.price = price;
    }

    public void setChange(double change) {
        this.change = change;
    }

}

Step 7: Applying Style (Please see the Official Tutorial, too.)

• CSS Stylesheets can be associated from within the HTML Host File or – preferably – from within the Module Definition XML:

  <module>
  ...
      <inherits name="com.google.gwt.user.theme.dark.Dark"/>
  ...
  </module>

• You can look up the name of the style rules (the CSS selector) for each widget by accessing the GWT API Reference via the Widget Gallery.
• Furthermore it’s possible to add custom HTML class names to the widgets and/or parts of it like e.g. Table Cells.

Step 8: Compiling a GWT Application (Please see the Official Tutorial, too.)

Aspect-oriented programming (AOP) is a programming paradigm that increases modularity by enabling improved separation of concerns. While object oriented programming paradigms support encapsulation of concerns, some concerns defy these forms of implementation and are called crosscutting concerns because they “cut across” multiple abstractions in a program. Logging is a common example of a crosscutting concern because a logging strategy necessarily affects every single logged part of the system.

For introducing AspectJ based AOP within the well-known Spring Framework, we just need a few lines of Spring Configuration

<!-- Activating AspectJ in Spring Config -->
<aop:aspectj-autoproxy/>

<!-- Configuring the Bean declaring the Aspect -->
<bean id="testAspect" class="spring.demo.TestAspect"/>

<!-- Some Test Bean to demonstrate the Aspect Execution -->
<bean id="test" class="spring.demo.Test"/>

plus: the Class declaring the Aspect, of course

@Aspect
public class TestAspect {

    @Pointcut("execution(* *(..))")
    public void methodExecution() {}

    @Around("spring.demo.AspectJTest.TestAspect.methodExecution()")
    public Object doTrace(ProceedingJoinPoint pjp) throws Throwable {
        Log log = LogFactory.getLog(pjp.getSignature().getDeclaringType());
        Object retVal;
        log.info("Starting method " + pjp.getSignature().toLongString());
        retVal = pjp.proceed();
        log.info("Ending method " + pjp.getSignature().toLongString());
        log.info("Method returned " + retVal);
        return retVal;
    }

}

As this Aspect triggers the @Around method on every method execution invoking the method boolean doSomething(boolean) on our Test Class

public class Test {
    public boolean doSomething(boolean param) {
        LogFactory.getLog(getClass()).info("About to return " + param);
        return param;
    }
}

will lead to something like the following sample output proving the execution of the TestAspect.doTrace(...) method:

Starting method public boolean spring.demo.Test.doSomething(boolean)
About to return true
Ending method public boolean spring.demo.Test.doSomething(boolean)
Method returned true

which is nice, actually. The Full Spring Guide on this can be found here

Most of the time, Mac OS X programs do not use environment variables like the “PATH”. However, sometimes I use tools that require such Variables. Contrary to well known places to put this kind of information in a Unix Environment (like /etc/profile, /etc/bashrc, ~/.profile, or ~/.bashrc files) the recommended way of doing this is the following:

1. Add the following File to your User Directory, if it does not already exist:
   ~/.MacOSX/environment.plist
2. Open it with some Text Editor and add the following XML Code
   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

   <plist version="1.0">
       <dict/>
   </plist>

3. Open the File in the Finder and add beneath “Root” an Environment Variable with the Mac OSX Plist Editor.
4. Log off and on again.
5. Enjoy.

The field of field of Business Process Execution is rising in importance and will make a fully web service oriented software development strategy of today really shining tomorrow.

What must one think of when it comes to “integrating” such an Engine with a Framework of Components primarily targeted at developing stand-alone “applications” for specified Business Purposes? Well, nothing stands alone anymore in these days and everthing is a process, isn’t it? Therefore, I think it would be nice to have in place

• A Web Service Oriented Architecture of the Application itself in order to allow the Business Process Execution Engine to automatically trigger any Task one could think of
• In addition to that a Task Management which is fully integrated into the Application in order to allow the User of the Application to go through all the Tasks which concern the Application and need Human Intervention by a User just like the one which happens to sit in front of the Application.

Such a Task Management will probably

• Provide a small layer of interface code which abstracts away the main aspects of typical Business Process Task Managements (should as a starting point work with jBPM and Intalio Task Management)
• Filter out and present only Tasks which concern Human Intervention in this Application itself.
• Provide useful mechanisms of linking such Tasks to Target Screens of the Application and maybe even prepopulate forms presented to the user with data needed for this task
• Such “Data needed for the Task” could be Data already available in the Process Instance and somehow transfered to the Application via the Task – but an even better Idea could be to prepare User Screens which need Human Confirmation directly by the Process Instance (via a Web Service) and after that Create the Task which links to this prepared “Screen”. (When thinking about it, what’s happening here is very similar to the approach of “Second Set of Eyes”. The Idea is in my mind that a Process could act just like a User which is not allowed to activate changes and prepare some “not-yet-activated” Data, while a Human User who is allowed to activate such changes could just confirm them when going through the Task List linking to such Screens of Prepared and Not-Yet-Activated Data).

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

Still astonishing when working in the arena of Java based so called “Enterprise level” Web Applications for some years is the fact how little effort regularly is invested into smooth deploying and upgrading of such applications. Let’s therefore shortly consider the main requirement aspects one has to keep in mind when developing software which doesn’t cause too many headaches at deployment time.

• There has to be some thoughtful Management of Configuration Data manipulable by the User of the Software Package in a way that makes sure that existing Configuration Data isn’t lost when deploying a new version of the software.
• This Configuration Management therefore also has to provide a mechanism which is able to migrate the User Configuration itself into some new Configuration Structure complying to what’s needed by the new Version of the Software.
• Of course, the Configuration Management has to work for all Configuration Data of the System including the Connection Parameters to other systems such as Databases.
• We need a Database Upgrade Mechanism which is able to automatically detect the Software version of a Database and to applying all Migration Processes needed to upgrade to the currently needed Version.
• In an ideal world, there would also be a Downgrade Path which allows to Downgrade to a previous Software Version without loosing the Data added to the System in the meantime. Well.
• We need some security which makes sure that Databases with Production Data are never migrated “by accident”.
• We have to take into account that for “Migrating a Database” we typically need more administrative database rights than for regular usage, e.g. when it comes to extending the Schema (applying DDL statements).
• There should also be some mechanism which takes care of transition with a working Test Environment to a Production Environment.

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

Provided you are already working with some JPA/Hibernate mapped Database, it would be very useful to have a generic and out-of-the-box working Database Import/Export mechanism at hand, which in the most generic case solely works on the JPA configuration/mapping already in place, for more sophisticated cases with some additional configuration. Such a mechanism should in my mind probably allow

• To export the whole Database in a Vendor Unspecific, Java centric way and serialize it to some appropriate (probably XML-based) Data Format
• To recover the whole Database to exactly the State represented in the Export.
• To limit the Export to some Tables/Entities to be exported.
• To make use of different Import Strategies when it comes to importing Entities into a non-empty Database. I think here of applying different Deletion Strategies – probably configurable per Entity Class – whenever importing instances of any given Class found in the Dump, cause I already stumbled upon practically applicable Use Cases for all of them:
  1. Deleting all (mapped) Entities in the Database.
  2. Deleting all Entities of the Hierarchy of the Class found in the Dump.
  3. Deleting all Entities of the Class found in the Dump.
  4. Deleting just the Entity found in the Dump itself.
  5. Not deleting anything, but just populating an eventually preexisting Entity found in the Database with the Properties found in the dumped Entity.
• To alternatively base the “Identity” of a Dumped Entity not on it’s Database Primary Key, but on some configurable “natural” Key Values which can be found among its Properties.
• To be aware of whether the Database Schema matches the Dump, and potentially also whether the Version of the Software working with the Data represented in the Database matches the Dump, and throw appropriate warnings and/or errors if not. (Maybe the desirable behaviour will depend on the requested Import Strategies for the Entities in the Dump.)
• To be able to import Dumps produced with older versions of the Import/Export Tool itself.

A bit more investigation needed. It could turn out, that the basic features can be relatively easily achieved based on Hibernates XML serialisation format. Surely, we remember: nothing is as easy as espected. (On the other hand: exactly because of this truth we should also be wise enough not to expect everything to be difficult. Provided the statement “nothing is as easy as espected” is true, our expectations will influence how hard our time with an issue will turn out to be in the end. Won’t they?

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

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)