Welcome to the Apache Tuscany Java DAS RDB FAQ page. Please help to keep the information on this page current.
\\
{panel:title=Apache Tuscany RDB DAS Frequently Asked Questions|borderStyle=solid|borderColor=#C3CDA1|titleBGColor=#C3CDA1|bgColor=#ECF4D1}
* [RDB DAS thread safety|#RDB DAS thread safety]
* [Migration from M2|#Migration from M2]
* [Handling internal/external transaction management|#transaction management]
* [Handling parent/child relationship|#handling parent/child relationship]
* [Handling parent/child relationship|#handling parent/child relationship]
* [How does DAS handle mapping between DataGraph properties and Database Metadata like table name, column name etc. during disconnected processing |#mapping]
* [no PK defined |#no PK defined]
\\
{panel}
h2. {anchor:* [RDB DAS thread safety}{bgcolor:#C3CDA1}RDB DAS thread safety{bgcolor}
DAS design should support thread safety, but we have done no explicit testing on this area.
Initializing a DAS and using across multiple DAS calls should be OK and safe as long as you are using the same config file. I'd recommend initializing the DAS in a sync method tough.support for generated keys|#RDB DAS support for generated keys]
* [How DAS works with Dataobjects|#How DAS works with Dataobjects]
* [What is Optimistic Concurrency Control?|#Optimistic Concurrency Control]
* [What is the purpose of many and keyRestricted attributes in Relationship?|#keyRestricted]
* [what is paging capability?|#paging]
* [Example to define the ResultSet shape Definition for a join in DAS|#ResultSet]
\\
{panel}
h2. {anchor:MigrationRDB DAS fromthread M2safety}{bgcolor:#C3CDA1}MigrationRDB DAS fromthread M2safety{bgcolor}
I'm getting "Feature 'Config' not found." after migrating my application for after M2 codebase.
There was a change (see http://issues.apache.org/jira/browse/TUSCANY-899). To fix this, changed the attribute "xmlns"'s value of the "config" tag to "http:///org.apache.tuscany.das.rdb/config.xsd". DAS design should support thread safety, but we have done no explicit testing on this area.
Initializing a DAS and using across multiple DAS calls should be OK and safe as long as you are using the same config file. I'd recommend initializing the DAS in a sync method tough.
h2. {anchor:transactionMigration from managementM2}{bgcolor:#C3CDA1}HandlingMigration internal/external transaction managementfrom M2{bgcolor}
In DAS Config, element ConnectionInfo has a boolean attribute managedtx (default true).
If it is true, DAS runtime manages transaction otherwise the caller is supposed to manage
transaction.
In cases, when the connection is externally passed (config file does not specify ConnectionInfo),
the managedtx attribute default value ( true) is assumed.I'm getting "Feature 'Config' not found." after migrating my application for after M2 codebase.
There was a change (see http://issues.apache.org/jira/browse/TUSCANY-899). To fix this, changed the attribute "xmlns"'s value of the "config" tag to "http:///org.apache.tuscany.das.rdb/config.xsd".
h2. {anchor:handling parent/child relationshiptransaction management}{bgcolor:#C3CDA1}Handling parentinternal/childexternal transaction relationshipmanagement{bgcolor}
If
In twoDAS tablesConfig, haveelement aConnectionInfo parent-childhas relationshipa butboolean theattribute querymanagedtx result set contains only columns from one table, does RDB DAS result DataGraph contain data from both parent and child table?
The RDB DAS will only populate a graph with data returned from the used query. If you want a
graph that contains data from related tables then the query provided must return that data
(typically a join). The relationship tests in the test suite demonstrate this.
If two tables have a parent-child relationship and the query result set contains columns from both tables, is the relationship analyzed by DAS when,
# DAS Config explicitly defines relationship
# DAS Config does not explicitly define relationship?
DAS supports some Convention over Configuration when it comes to supporting implied relationships.
[http://cwiki.apache.org/confluence/display/TUSCANY/ConventionOverConfiguration]
[http://cwiki.apache.org/confluence/display/TUSCANY/ForeignKeyRepresentationAndManagement]
[http://cwiki.apache.org/confluence/display/TUSCANY/WorkingWithRelationships]
Also, see test: ImpliedRelationshipTests.testAddNewOrder()
So, in summary, if the query has a where clause specifying the relationship, there is no need to
have any relationship definition in config file as long as the column names (PK, FK) follow the
naming conventions.
In the absence of naming conventions, the relationship needs to be explicitly defined in the config,
so that the query result is mapped against it and the necessary result DataGraph is represented
reflecting the relationship.
h2. {anchor:mapping}{bgcolor:#C3CDA1}How does DAS handle mapping between DataGraph properties and Database Metadata like table name, column name etc. during disconnected processing. {bgcolor}
DAS supports this mapping using DAS Config and in the absence of that using Convention over Configuration.
[http://cwiki.apache.org/confluence/display/TUSCANY/ConventionOverConfiguration]. DataObject graph
change summary contains old as well as modified values. Using this change summary and config/conventions DAS can support the necessary mapping.
h2. {anchor:no PK defined}{bgcolor:#C3CDA1}no PK defined {bgcolor}
Does DAS support working with tables that have no PK defined?
DAS mandates PK for any table, either specified in DAS Config or by following convention. In absence
of both of these, DAS throws an error.
h4. How does DAS support database generated keys?
This is supported for INSERT operation - either explicit insert (SQL INSERT statement as DAS command) or generated insert.
In case of generated insert, the DAS config needs to have Column element having attribute "generated" set to "true". This attribute is not needed in case of explicit insert.
In case of generated insert, "generated" attribute from Column element in Config is checked to form the appropriate insert statement. The jdbc supported PreparedStatement.getGeneratedKeys() is used to fetch the values being generated by the database. In case of generated insert, the value thus returned is set in DataGraph.
This feature is not supported on all versions of Oracle drivers, so DAS does not use this functionality if database is Oracle.
h4. What manipulations does DAS provide for DataObjects?
DAS can get DataObject using Dynamic approach or Static approach. In Dynamic approach the query result set is used to form the DataObject. In static approach, DAS Config's DataObjectModel attribute needs a valid value, using which the DataObjects are created.
For more details see [http://cwiki.apache.org/confluence/display/TUSCANY/Graph+Merge].
h4. When there is 1:n relationship between 2 tables, say Department:Employee, and there is a DataGraph with this relationship present, can one Employee DataObject from this graph be associated with 2 different Department DataObjects, using DAS Java Client? i.e. can 1:n relationship be changed to n:n using SDO?
No, when this is attempted, SDO maintains referential integrity. e.g.
If you have a dept1 with emp1 and then execute:
dep2.getEmployees.add(emp1)
the graph will automatically remove emp1 from dep1's list of employees and
you are left with valid 1:m relationship.
h4. What is Optimistic Concurrency Control?
See details on [http://cwiki.apache.org/confluence/display/TUSCANY/OptimisticConcurrencyControl]
By default OCC is ON. With this, in generated UPDATE statement, any column undergoing change also gets included in the WHERE clause.
Other than that, in DAS Config, in <Table> element , the <Column> element can have two boolean attributes:- managed(default true), collision
When collision=true for a column, during UPDATE statement generation, that column is included
in the WHERE clause.
When managed=true for a column, during UPDATE statement generation, that column (needs to be BigDecimal) value is incremented by 1 and used in the SET clause in UPDATE.
managed=true, is effective only when collision=true, else managed attribute value is ignored.
h4. What is the purpose of many and keyRestricted attributes in Relationship?
many=true allows for 1:n relationship. If it is false, it's 1:1 relationship. In case of 1:1 relationship, if keyRestricted is not specified, the link (relationship) between the parent and child rows can be broken, by setting the parentKeyTable's row to null/deleting the row. Also, a different parent row can be associated to the child row, which has one pre-existing parent row association. If keyRestricted=true, this kind on change in existing relationship is not allowed, user will get exception 'Can not modify a one to one relationship that is key restricted'.
h4. In case of parent-child relationship, how to traverse back and forth?
If by Convention over Configuration/from DAS Config there is a name to a relationship, the opposite relationship is named with _opposite appended to it.
e.g. Consider two tables (CUSTOMER, ORDER) each with a PK named "ID". Also, ORDER has a FK named CUSTOMER_ID. The DAS recognizes this convention and assumes a one:many relationship between CUSTOMER and ORDER. In the fully dynamic case, a read of CUSTOMER and ORDER tables using a join will result in a graph of CUSTOMER DataObjects along with their related ORDERS.(name of relationship is ORDERS now.)
The property for the CUSTOMER Types list of ORDERs is named "ORDER" so:
DataObject order = cust.getDataObject("ORDER[1]");
The name of the property in the ORDER Type that references the parent CUSTOMER, is
DataObject cust = order.getDataObject("CUSTOMER_opposite")
h4. what is paging capability?
What is currently available in DAS is detailed on [http://cwiki.apache.org/confluence/display/TUSCANY/WorkingWithPaging]
Other than sequential page access(pager.next(), pager.previous()), random access is also
allowed using pager.getPage(number).(default true).
If it is true, DAS runtime manages transaction otherwise the caller is supposed to manage
transaction.
In cases, when the connection is externally passed (config file does not specify ConnectionInfo),
the managedtx attribute default value ( true) is assumed.
h2. {anchor:handling parent/child relationship}{bgcolor:#C3CDA1}Handling parent/child relationship{bgcolor}
*Question:* If two tables have a parent-child relationship but the query result set contains only columns from one table, does RDB DAS result DataGraph contain data from both parent and child table?
The RDB DAS will only populate a graph with data returned from the used query. If you want a
graph that contains data from related tables then the query provided must return that data
(typically a join). The relationship tests in the test suite demonstrate this.
*Question:* If two tables have a parent-child relationship and the query result set contains columns from both tables, is the relationship analyzed by DAS when,
# DAS Config explicitly defines relationship
# DAS Config does not explicitly define relationship?
DAS supports some Convention over Configuration when it comes to supporting implied relationships.
[http://cwiki.apache.org/confluence/display/TUSCANY/ConventionOverConfiguration]
[http://cwiki.apache.org/confluence/display/TUSCANY/ForeignKeyRepresentationAndManagement]
[http://cwiki.apache.org/confluence/display/TUSCANY/WorkingWithRelationships]
Also, see test: ImpliedRelationshipTests.testAddNewOrder()
So, in summary, if the query has a where clause specifying the relationship, there is no need to
have any relationship definition in config file as long as the column names (PK, FK) follow the
naming conventions.
In the absence of naming conventions, the relationship needs to be explicitly defined in the config,
so that the query result is mapped against it and the necessary result DataGraph is represented
reflecting the relationship.
*Question:* When there is 1:n relationship between 2 tables, say Department:Employee, and there is a DataGraph with this relationship present, can one Employee DataObject from this graph be associated with 2 different Department DataObjects, using DAS Java Client? i.e. can 1:n relationship be changed to n:n using SDO?_
No, when this is attempted, SDO maintains referential integrity. e.g.
If you have a dept1 with emp1 and then execute:
dep2.getEmployees.add(emp1)
the graph will automatically remove emp1 from dep1's list of employees and
you are left with valid 1:m relationship.
*Question:* In case of parent-child relationship, how to traverse back and forth?
If by Convention over Configuration/from DAS Config there is a name to a relationship, the opposite relationship is named with _opposite appended to it.
e.g. Consider two tables (CUSTOMER, ORDER) each with a PK named "ID". Also, ORDER has a FK named CUSTOMER_ID. The DAS recognizes this convention and assumes a one:many relationship between CUSTOMER and ORDER. In the fully dynamic case, a read of CUSTOMER and ORDER tables using a join will result in a graph of CUSTOMER DataObjects along with their related ORDERS.(name of relationship is ORDERS now.)
The property for the CUSTOMER Types list of ORDERs is named "ORDER" so:
DataObject order = cust.getDataObject("ORDER[1]");
The name of the property in the ORDER Type that references the parent CUSTOMER, is
DataObject cust = order.getDataObject("CUSTOMER_opposite")
h2. {anchor:mapping}{bgcolor:#C3CDA1}How does DAS handle mapping between DataGraph properties and Database Metadata like table name, column name etc. during disconnected processing. {bgcolor}
DAS supports this mapping using DAS Config and in the absence of that using Convention over Configuration.
[http://cwiki.apache.org/confluence/display/TUSCANY/ConventionOverConfiguration]. DataObject graph
change summary contains old as well as modified values. Using this change summary and config/conventions DAS can support the necessary mapping.
h2. {anchor:no PK defined}{bgcolor:#C3CDA1}no PK defined {bgcolor}
Does DAS support working with tables that have no PK defined?
DAS mandates PK for any table, either specified in DAS Config or by following convention. In absence
of both of these, DAS throws an error.
h2. {anchor:RDB DAS support for generated keys}{bgcolor:#C3CDA1}RDB DAS support for generated keys {bgcolor}
This is supported for INSERT operation - either explicit insert (SQL INSERT statement as DAS command) or generated insert.
In case of generated insert, the DAS config needs to have Column element having attribute "generated" set to "true". This attribute is not needed in case of explicit insert.
In case of generated insert, "generated" attribute from Column element in Config is checked to form the appropriate insert statement. The jdbc supported PreparedStatement.getGeneratedKeys() is used to fetch the values being generated by the database. In case of generated insert, the value thus returned is set in DataGraph.
This feature is not supported on all versions of Oracle drivers, so DAS does not use this functionality if database is Oracle.
h2. {anchor:How DAS works with Dataobjects}{bgcolor:#C3CDA1}How DAS works with Dataobjects{bgcolor}
DAS can get DataObject using Dynamic approach or Static approach. In Dynamic approach the query result set is used to form the DataObject. In static approach, DAS Config's DataObjectModel attribute needs a valid value, using which the DataObjects are created.
For more details see [http://cwiki.apache.org/confluence/display/TUSCANY/Graph+Merge].
h2. {anchor:Optimistic Concurrency Control}{bgcolor:#C3CDA1}What is Optimistic Concurrency Control?
{bgcolor}
See details on [http://cwiki.apache.org/confluence/display/TUSCANY/OptimisticConcurrencyControl]
By default OCC is ON. With this, in generated UPDATE statement, any column undergoing change also gets included in the WHERE clause.
Other than that, in DAS Config, in <Table> element , the <Column> element can have two boolean attributes:- managed(default true), collision
When collision=true for a column, during UPDATE statement generation, that column is included
in the WHERE clause.
When managed=true for a column, during UPDATE statement generation, that column (needs to be BigDecimal) value is incremented by 1 and used in the SET clause in UPDATE.
managed=true, is effective only when collision=true, else managed attribute value is ignored.
h2. {anchor:keyRestricted}{bgcolor:#C3CDA1}What is the purpose of many and keyRestricted attributes in Relationship? {bgcolor}
many=true allows for 1:n relationship. If it is false, it's 1:1 relationship. In case of 1:1 relationship, if keyRestricted is not specified, the link (relationship) between the parent and child rows can be broken, by setting the parentKeyTable's row to null/deleting the row. Also, a different parent row can be associated to the child row, which has one pre-existing parent row association. If keyRestricted=true, this kind on change in existing relationship is not allowed, user will get exception 'Can not modify a one to one relationship that is key restricted'.
h2. {anchor:paging}{bgcolor:#C3CDA1}what is paging capability? {bgcolor}
What is currently available in DAS is detailed on [http://cwiki.apache.org/confluence/display/TUSCANY/WorkingWithPaging]
Other than sequential page access(pager.next(), pager.previous()), random access is also
allowed using pager.getPage(number).
h2. {anchor:ResultSet}{bgcolor:#C3CDA1} Example to define the ResultSet shape Definition for a join in DAS{bgcolor}
Doing:
{code}
Select a.dept_name, b.employee_name
from dept a, emp b
where a.id = b.dept_id (+)
{code}
How do I define an Explicit ResultSet shape definition for the resultset from a join?
You can find some information on the DAS User Guide [1]. There are
couple test cases that also show this working, here is one test case
[2] and it's config file [3].
Amita is also working on getting support for passing ResultDescriptor
for dynamic Commands [4], if that would be useful for you.
[1] http://incubator.apache.org/tuscany/explicit-resultset-shape-definition.html
[2]https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/RelationshipTests.java
[3]https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/resources/companyMappingWithResultDescriptor.xml
[4] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19886.html
|