db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [jira] Commented: (DERBY-334) Add initial SQL support for XML datatype/functions in Derby, based on SQL/XML specs.
Date Sat, 04 Jun 2005 03:52:10 GMT
Army wrote:
> Daniel John Debrunner (JIRA) wrote:
> 
>>     [
>> http://issues.apache.org/jira/browse/DERBY-334?page=comments#action_12312598
>> ]
>> Daniel John Debrunner commented on DERBY-334:
>> ---------------------------------------------
>>
>> From a quick look at the initial patch it seems the XML data type
>> spills over into the SQL layer, through use of classes in the new
>> package  impl.sql.xml.
> 
> 
> [ snip ]
> 
>> It may be that  you just created a sql.xml package instead of puting
>> the classes in the iapi.types package, but I did see a reference to
>> the DataDictionary  in one of the classes in impl.sql.xml.
> 
> 
> At first I had indeed put the XML implementation classes (the ones in
> sql.xml) into the iapi.types package--and that worked just fine (I just
> imported the DataDictionary into the iapi.types package, which didn't
> show any problems).
> 
> When I started the code "re-org" though, I decided to move the classes
> to impl.sql.xml because 1) the package name seemed to make more sense to
> me ("sql.xml" => SQL/XML, and "impl" => these are the implementation
> classes, not the interface/type classes); and 2) I don't know how many
> more XML type implementations we're going to have in the future, but it
> seemed like it would be cleaner to have all of them isolated into their
> own package, instead of cluttering the iapi.types package with
> who-knows-how-many XML impl files.

The current types are SQL types, e.g. SQLInteger, but they live in the
types directory. Thus the correct place for a SQL XML type is the api
directory. The {iapi/impl}/sql packages are for the SQL compilation and
execution engine.
In some ways Cloudscape split too much into api and implementation and
the types package was attempt to fix that, there used to be an impl
types. Looking at it, Derby will only ever need one implementation for
INTEGER so that's why the types moved to a single package. In only rare
cases, DECIMAL, maybe XML does Derby need separate implementations.

> That said, moving impl.sql.xml back to iapi.types is certainly doable,
> but I'm not sure if that would handle the issue you bring up--by using
> DataDictionary in the XML impl class, we're still crossing the two
> layers...So maybe that's the more fundamental issue...
> 
>> I'm not sure if we need the double indirection,
>> XMLDataValue->XML->implementation.
> 
> 
> I've gone over that question a couple of times, too.  I've re-organized
> the XML type classes several times since I first began, so maybe this
> double indirection is a result of an old class organization.  I'll try
> to look at it again to see if I can explain why I did it...

There is a theory of "You ain't going to need it", which really says
only code what you need. If we only need a single XML implementation at
the moment then code it that way, just allow the on-disk format to have
multiple implementations in the future. The api is XMLDataValue and the
implementation XML. Just an idea, again I think in Cloudscape we built
too much infrastructure for multiple implementations, where in many
cases one will suffice.


Dan.



Mime
View raw message