make EntityResolver pluggable, SqlMapClasspathEntityResolver found wanting
--------------------------------------------------------------------------
Key: IBATIS-140
URL: http://issues.apache.org/jira/browse/IBATIS-140
Project: iBatis for Java
Type: Improvement
Components: SQL Maps
Versions: 2.0.9b
Environment: IBatis 2.0.9b on WAS 5.1.2 on JDK 1.4.2 on vanilla Windows 2000
with service packs.
Reporter: Ulrich Kroener
Priority: Minor
Hi there,
I'm working on a fairly large project that has decided to use IBatis as a
persistency library. There are about 5 schemas, each schema has about 20
tables, each table on average 10 columns. For each table we need to write CRUD
calls. Given the volume of the above, hand-crafting all of the SQL maps is out
of the question.
This is why I have written a handy generator program, which transforms what is
essentially DDL (plus some XML descriptions) into POJOs, IBatis SqlMaps, and
DAO classes. Sme day I'm planning to publish it, and/or re-write it using
XDoclet, but not right now.
Of course, it is interesting to have that generator re-generate the classes and
XML files at our whim, but it is also interesting to write custom SQL
statements which we do not wish to generate.
Hence, I'm attempting to split the SQLmap into two parts, one is
auto-generated, the other hand-written. I'm trying to use XML external parsed
entities (inside of a DTD) in order to achieve just that.
So here it comes. I have a file CountryPairing.xml which maps a CountryPairing
bean to a table of the same name. This is where I'm referring to a DTD.
==================
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE sqlMap SYSTEM "ExCountryPairing.genmap.dtd" >
<sqlMap namespace="&namespace;">
&typeAliasRequest;
&genDelete;
<!- custom SQL maps follow here -->
</sqlMap>
=================
Then the CountryPairing.dtd is as follows:
::::::::::::::::
<!ENTITY % theSqlMap PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN"
"http://www.ibatis.com/dtd/sql-map-2.dtd";>
%theSqlMap;
<!-- namespace -->
<!ENTITY namespace 'CountryPairing'>
<!-- typeAlias -->
<!ENTITY parameterClassId 'myRequest'>
<!ENTITY typeAliasRequest '
<typeAlias alias="¶meterClassId;" type="java.util.Map"/>
'>
<!-- delete -->
<!ENTITY genDelete '
<delete id="delete" parameterClass="¶meterClassId;">
delete from CountryPairing
where
CountryPairingId = #parameterMap.countryPairingId#
</delete>
'>
::::::::::::::::
The above is saying that I have a parameterClass which implements a Map. The
map has a property parameterMap.countryPairingId.
I plan to hand-write the XML while re-generating the DTD on a periodic basis.
Then I would regression-test the whole SQL map.
But the entity resolver inside of 2.0.9b is not smart enough for external
references, and there is no possibility to hand it a different entity resolver
at runtime.
It works though if I use internal references.
Here is the place where to improve: Both the classes SqlMapParser and
SqlMapConfigParser will pass an instance of SqlMapClasspathEntityResolver to
NodeletParser. IBatis has plenty of clever and well-written classes, but
SqlMapClasspathEntityResolver is not one of those.
One could do much better by being able to specify which EntityResolver IBatis
is going to use. Then I could jsut plug in a
org.apache.xml.resolver.tools.CatalogResolver. This will also make deployment
easier, in being able to catalog the DTDs and XSDs used.
See http://xml.apache.org/commons/components/resolver/resolver-article.html
As Norman Walsh points out, "May All Your Names Resolve Successfully! We hope
that these classes become a standard part of your toolkit".
Thanks for reading all this and bearing with me.
Ulrich Kroener
Consultant at Nike Belgium
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
