Since RIFE's query builders already create a very convenient database independence layer, it was only a matter of time to provide a method to easily save and restore beans from a database in one line.

The magic happens in the package com.uwyn.rife.database.querymanagers.generic, and more specifically the interface GenericQueryManager. You obtain an instance of it by using the GenericQueryManagerFactory class in the same package.

Let's say you've got a Java bean with the class name Article. You obtain a generic query manager for it like this:

GenericQueryManager manager =
  GenericQueryManagerFactory.getInstance(datasource, Article.class);

The 'datasource' parameter of course corresponds to the database in which you want to store the bean's data. Before being able to store data in a database, the correct structure has to be created first, of course. This is done like this:

manager.install();

Should you ever want to remove it again, then you can use the remove() method that does just that.

Useful Information Note that there currently isn't a builtin mechanism for determining if a manager has already been installed in the database. A possible workaround is to handle the possible exception thrown by install(). try { manager.install(); } catch(ExecutionException e) { Logger.getLogger("yourpackage").warning("The manager couldn't be installed, "+ "the table structure probably already exists."); Logger.getLogger("yourpackage").warning(ExceptionUtils.getExceptionStackTrace(e)); }

Once you have created the database structure, you can use the following methods to work with an instance of the bean:

Article article1 = new Article();
Article article2 = new Article();
Article article3 = new Article();
Article article4 = null;

int id1 = manager.save(article1);     // stores a new bean
int id2 = manager.save(article2);     // stores a new bean
int id3 = manager.save(article3);     // stores a new bean
article4 = (Article)manager.restore(id1);
                                      // retrieves the bean's data

article4.setName("new name");
manager.save(article4);               // updates the bean's data

List list = manager.restore();        // get list of all beans
List list = manager.restore(manager.getRestoreQuery()
    .where("sectionid", "=", sectionidINeed));
                                      // get selective list of beans

boolean result = manager.delete(id1); // deletes the bean's data

You probably noticed that the generic query manager assumes one thing: each bean has to have an integer property that will be used as an identifier (primary key). By default, the name of this property is id, but you can use any other by setting the identifier(true) constraint on the property that should be used as primary key instead.

Useful Information The initial value of the id property will dictate how the GenericQueryManager will treat identifiers for the bean: values of 0..n will be directly used as identifiers and make the save method update existing data, a value of -1 will produce auto-incrementing identifiers and make the save method insert new data.

The API and functionalities of the generics query manager are currently in an embryonal state, but what's available is stable and fully functional. It's already being provided at this time to check upon its usage patterns. The full-featured API that will be available in the next release will focus even more on providing quick and intuitive database interaction without having to learn all the details of the query builders.

A recent change to the GenericQueryManager is the addition of partial queries. This allows the user to modify the query on the fly, without having to go to the trouble of creating their own QueryManager.

Article article1 = new Article("title");
Article article2 = new Article("othertitle");

manager.save(article1);
manager.save(article2);

List articleList = manager.restore(manager.getRestoreQuery().where("title", "=", "othertitle"));

In this example articleList will now contain one bean, article2. In addition you also have getDeleteQuery() which will allow you to customize the delete() method.

It is possible to chain query conditions together, for example

manager.restore(manager.getRestoreQuery()
                       .where("title", "=", "othertitle")
                       .and("author", "=", "Samuel Beckett"))

The query conditions can be dynamic; the "whereAnd" and "whereOr" methods insulate you from piecing together SQL syntax for dynamic queries.

RestoreQuery query = manager.getRestoreQuery();
if (searchByAuthor)
    query.whereAnd("author", "=", author);
if (searchByTitle)
    query.whereAnd("title", "=", title);

Query parameters can be specified in any order; for example, you can call field() after you've already called where(). This is often helpful when building complex dynamic queries.