Hi Dirk,
Dirk Kraemer wrote:
>Hi Luca,
>
>thank you for your comments.
>
>If I do not misunderstand you, your suggestion is to use a mechanism
>to create unique ids that is independend from the underlying
>database system.
>
Yes, it's right.
It could be useful to make a prototype application that is db-independent.
>I agree that this would be nice to have within dbforms.
>Currently there is the possibility for each dbforms developer
>to plug in an arbitrary id generator via pre-insert interceptor code.
>
I use the id generator in this manner:
// this class extends a class that extends DbEventInterceptorSupport ...
public class PropertiesInterceptor extends com.pow2.dbforms.Interceptor
{
...
/**
* Get a new primary key for Property table;
*
* @param request Description of the Parameter
* @param fieldValues Description of the Parameter
* @param config Description of the Parameter
* @param con Description of the Parameter
* @return Description of the Return Value
* @exception ValidationException Description of the Exception
*/
public int preInsert(HttpServletRequest request,
Hashtable fieldValues,
DbFormsConfig config,
Connection con)
throws ValidationException
{
DAO dao = DAO.instance(); // wraps IdGenerator ...
long nextVal = -1;
try
{
nextVal = dao.getNewKey(); // get the new key;
}
catch (Exception e)
{
return DENY_OPERATION; // or **better**: throw new
ValidationException(e);
}
// store the new key...
fieldValues.put("PROPERTYID", String.valueOf(nextVal));
return GRANT_OPERATION;
}
...
}
>I used this approach for an Dbms that did not have the functionality
>to create unique ids. But to have it as a standard functionality
>would surely be better. And more portable...
>
>Am I right that your current code needs a dbms that supports
>serializable transactions? The (read-increment-writeback) operation
>must be atomic and protected.
>
Yes. You must use an ACID rdbms.
I usually use Postgresql for open source projects or MS SQL Server, IBM
DB2, Oracle 8i
for "commercial" projects.
Up to now I never used MySQL Max, but I should test it soon.
When I start to develope a web app for an "internal" project (a "demo"),
I start with Postgresql 7.x.
Then I can move on other dbs.
If a customer wants specific database features... ok, I can use them.
>
>However, I think we still need a possibility to handle those
>databases that are already there and use dbms internal generators.
>
>
I never used Turbine's Torque persistence layer (argh !!), so I don't
know how db-adapters are implemented.
Anyway, the concept of db-adapter is also presented into the Scott
Ambler's persistence layer paper
http://www.ambysoft.com/persistenceLayer.html
I think that a FactoryMethod design pattern should solve the problem.
A client can choose a db-adapter class sending a message to a
adapter-creator object.
The creator returns the db-adapter implementation for a specific db.
Every db-adapter should have the same interface.
This interface can have a method like "getNewKey".
We can provide a default (abstract ?) adapter superclass with the
getNewKey method that wraps the IdGenerator.getNewKey().
Other adapters can extend that class and override the getNewKey method.
So, if your db is supported, you can use its db-adapter (to have better
performances, etc).
If your rdbms is not into the list, you can use the "default"
db-adapter implementation.
Its a lof of time that I don't contribute to DbForms, anyway I remember
that the "bounded navigation" events selection uses
an abstract factory d.p. (because of prev and next events).
>
>Regards and thanks again
>
>Dirk
>
>_______________________________________________________________
>
>Don't miss the 2002 Sprint PCS Application Developer's Conference
>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
>_______________________________________________
>DbForms Mailing List
>
>http://www.wap-force.net/dbforms
>
>
>
>
>
Regards,
Luca
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
DbForms Mailing List
http://www.wap-force.net/dbforms
