Hello Christopher,
Some comments in line ...
Christopher Holtz wrote:
Hello Tuscany,
I am working on building a DAS implementation for an old hierarchical
database and am looking at Tuscany as *the* DAS reference implementation.
Several issues around applyChanges are troubling me and I'm hoping to
start
a dialog to address them (or even better get a really obvious answer that
I'm missing)
When a client returns a modified DataGraph back to a DAS instance,
that DAS
needs some basic information such as which Database, which Table, and
which
specific row(s) the now modified data originally came from before it can
start comparing old values, etc.
How does a DAS get this high level information from an incoming
DataGraph?
Is there a way to somehow tie the incoming DataGraph back to the initial
Command that produced it? Holding state in the DAS sounds like cheating
since it would break the fundamental SDO concepts, plus the SDO spec
mentions being able to take a DataGraph produced by one DAS and return
it to
another for changes.
The RDB DAS instance is configured with a database connection that it is
to work with. Also, the DAS may be configured with metadata regarding
the tables it is working with. In the absence of configuration
metadata, the DAS can make some assumptions about the mapping of
DataObjects to Tables/Columns (
http://wiki.apache.org/ws/ConventionOverConfiguration ).
The DataObject graph change summary contains all the original state as
well as any modifications made. The RDB DAS can use this change summary
to generated the required database update statements without needing to
know the original query.
Assuming we know the database and table somehow, what happens in the case
where the primary key(s) are not included in the DataObject? do we put
them
in the DataObject anyways during retrieval. And even so what about
the case
where the table has no unique primary key (is that even legal in the
relational world)?
The metadata the DAS instance is created with may include primary key
definitions. If there is no key definitions then the DAS will make
assumptions about the key (convention over config again). If there is
no PK config info and there are no matching conventions then the DAS
will throw an error since it requires a PK to generate the needed update
statements.
Thanks,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
