At the moment, the DAS allows users to create a "ResultSetShape"
object to describe the tables and column in a ResultSet. Tuscany 231
was opened to move from this object to the ResultDecriptor object in
the DAS config.
However, this raises an issue with the current codebase.
ResultDescriptor is scoped to Command in the Config, so it forces the
user to create a CommandGroup rather than creating a command directly.
Here's an example from ConverterTests where we don't have to do this
today:
//Create and initialize command to read customers
Command read = Command.FACTORY.createCommand("select * from CUSTOMER
where ID = 1", getConfig("CustomerConfigWithConverter.xml"));
read.setConnection(getConnection());
String[] columns = { "ID", "LASTNAME", "ADDRESS" };
String[] tables = { "CUSTOMER", "CUSTOMER", "CUSTOMER" };
Type[] types = { SDODataTypes.INTEGEROBJECT, SDODataTypes.DATE,
SDODataTypes.STRING };
ResultSetShape shape = new ResultSetShape(tables, columns, types);
read.setResultSetShape(shape);
//Read
DataObject root = read.executeQuery();
With this XML file:
<Config
xsi:noNamespaceSchemaLocation="http:///org.apache.tuscany.das.rdb/config.xsd";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<Table tableName="CUSTOMER">
<Column columnName="ID" primaryKey="true"/>
<Column columnName="LASTNAME"
converterClassName="org.apache.tuscany.das.rdb.test.mappings.SillyDateStringConverter"/>
</Table>
</Config>
If we switch to ResultDescriptor, we would have to create a
CommandGroup XML with a single Command to get this to work.
Possible solutions:
1) Switch to ResultDescriptor but keep ResultSetShape around for this
purpose. This seems like a bad option because it muddles the
programming model.
2) Get rid of the ability to create Command objects directly and make
CommandGroup the only means of interaction with the DAS. I don't like
this option because it takes away a lot of our "simple" scenarios.
3) Move to ResultDescriptor and remove the ability to specify a shape
for a single Command. This is probably OK if we consider specifying a
shape to be an infrequent scenario
4) Have a ResultDescriptor scoped at Config and one scoped at Command.
Probably way too confusing.
5) Some other clever refactoring of Command/CommandGroup. Not sure
what this is. We could remove the CommandFactory and allow the
creation of new Command objects from CommandGroup. That doesn't really
help with this problem, but may be something we want to consider in
general.
Any thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
