A clever use of and where the is in the ${dialect} file will
give some pretty reasonable flexability without the need to exploit any
bugs. I have recently posted a JIRA feature request precisely to help
address key generation aspect of the cross-DB compatability issue more
easily using propertie
Larry,
thank
you very much for your reply.
I
don't remember if it's possible to load a SQL map xml files at
runtime.
If
yes, we could leave the sqlMapConfig file empty (with non sqlMap tags) and then
load the sqlMap files at runtime, looking before in the "dialect"
folder; if it's not p
I would try a structure like this:Set up your SqlMapConfig.xml file to load a properties file, and in that properties file specify the database dialect (i.e., dialect=mysql, or
dialect=oracle, etc...). Then, you can load the common sqlmaps from a common location, and the dialect specific ones usin
Hi
all,
my company is
starting a new data-centric application that should be
database-indipendent (e.g. work with MySql, Oracle, SQL-Server, DB2
ecc.).
We don't want to use
Hibernate because we used it in the past e we dont' like it.
I've found iBATIS,
read the documentation and I like it
