RIFE : Generic query manager
This page last changed on Jun 18, 2006 by koreth.
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:
Should you ever want to remove it again, then you can use the remove() method that does just that.
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.
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.
|Document generated by Confluence on Oct 19, 2010 14:56|