RE: [JBoss-user] select count(*) from ... during CMP bean creatio n
Hi, I'm not sure I understand exactly which classes you propose modifying. It looks to me as if having JAWSPersistenceManager get the class of a JDBCCommandFactory from the container metadata, and having JDBCCommandFactory descendants (and the commands they create) implement the db specific behaviour is a possibility. Is this what you were proposing? thanks david jencks On 2001.05.15 04:15:40 -0400 [EMAIL PROTECTED] wrote: It occurs to me that if you expect the insert to normally succeed, you could start by trying the insert, if it fails you can investigate further with the count(*) query to see if the problem is the existing row. This would be one access for success, 2 for failure instead of 1+ for failure and 2 for success (Even if the key is missing, the insert might fail for other reasons.. maybe a unique index). I support this idea. Some time before I've used the same technique for the small datawarehouse, it worked perfectly. Another possibility (presumably for the future) would be to have JAWS customizable with a plugin/database vendor and recognize their error messages. That would be great. I've tried to customize the JAWS jdbc command object, but left that idea because of complexities: The reason is the inheritence of all JDBCcommand. Usually one need to change only JDBCCommand in order to customize it to the database, but then you're not able to tell all other commands to use new one. I suggest that we define the abstract class that can takes JDBCCommand as constructor parameter and then invokes all methods on the passed JDBCCommand. All concrete commands should be inherited from that abstract class. It seems to me that in this case we will be able to customize JAWS for different databases easily. Regards, Roman ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] select count(*) from ... during CMP bean creatio n
It looks to me as if having JAWSPersistenceManager get the class of a
JDBCCommandFactory from the container metadata, and having
JDBCCommandFactory descendants (and the commands they create)
implement the
db specific behaviour is a possibility. Is this what you
were proposing?
Not exactly. Yes, you're right that if you go for the JDBCCommandFactory
then you're able to provide commands that can implement the database
specific functionality. However, what I propose, is to reuse the existing
commands, because almost the all functionality remains the same.
For example, if I want to override the setParameter(PreparedStatement, int,
int, Object), getResultObject(ResultSet, int, Class) or jdbcExecute(Object)
in the JDBCCommand class (to customize the serialization for example), I can
do this by
public class MyJDBCCommand extends JDBCCommand {
protected void setParameter(...) {...}
protected Object getResultObject(...) {...}
protected jdbcExecute(Object arg) {...}
}
All existing JDBC commands could be reused (the code there is basically
business logic, and not DB specific). But I cannot do this because all of
them are inherited from the JDBCCommand, not MyJDBCCommand.
That is my vision of the problem.
My idea is that all JDBC commands use delegation instead of the inheritence.
Then if I'm able to pass my JDBCCommand class as the parameter, I can reuse
current code and don't worry about the creating a bunch of classes by
copying them from existing code.
Regards,
Roman.
___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
