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 JDBC<command>. 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
