Page History

Welcome

to

the

Apache

Tuscany

Java

DAS

RDB

FAQ

page.

Please

help

to

keep

the

information

on

this

page

current.

Anchor
RDB DAS thread safety RDB DAS thread safety

Background Color
color #C3CDA1
RDB DAS thread safety

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.

Anchor
Migration from M2 Migration from M2

Background Color
color #C3CDA1
Migration from M2

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".

Anchor
transaction management transaction management

Background Color
color #C3CDA1
Handling internal/external

transaction

management

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.

Anchor
handling parent/child relationship handling parent/child

relationship

Background Color
color #C3CDA1
Handling parent/child

relationship

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,

1. DAS

1. Config

1. explicitly

1. defines

1. relationship

2. DAS

1. Config

1. does

1. not

1. explicitly

1. define

1. 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")

Anchor
mapping mapping

Background Color
color #C3CDA1
How does DAS handle mapping between DataGraph properties and Database Metadata like table name, column name etc. during disconnected processing.

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.

Anchor
no PK defined no PK defined

Background Color
color #C3CDA1
no PK defined

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. Having PK ensures uniqueness of Data Object - returned as query result.

Anchor
RDB DAS support for generated keys RDB DAS support for generated keys

Background Color
color #C3CDA1
RDB DAS support for 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.

New boolean attribute added in Config - "generatedKeysSupported". User can set true/false for this in Config. If not set in Config, JDBC Metadata API check supportsGetGeneratedKeys() is done to detect whether to use auto generated keys during INSERT.

Note: For Derby, always assumed generatedKeysSupported=TRUE. This is because current Derby API return FALSE for supportsGetGeneratedKeys(), as it is partially implemented, but in DAS context, this support is sufficient.

This gived user flexibility to turn on/off support for database generated keys during INSERT based on the
database vendor/driver version in use.

Anchor
How DAS works with Dataobjects How DAS works with Dataobjects

Background Color
color #C3CDA1
How DAS works with 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

.

Anchor
Optimistic Concurrency Control Optimistic Concurrency Control

Background Color
color #C3CDA1
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.

Anchor
keyRestricted keyRestricted

Background Color
color #C3CDA1
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'.

Anchor
paging paging

Background Color
color #C3CDA1
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).

Anchor
ResultSet ResultSet

Background Color
color #C3CDA1
Example to define the ResultSet shape Definition for a join in DAS

Doing:

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

.

Allow passing ResultDescriptor to Dynamic Commands. i.e. Command x = das.createCommand("y");
x can have set/get of single/list of ResultDescriptors. Useful for databases like Oracle
which require user to pass ResultDescriptor and for cases when the commands are created dynamically
using createCommand()

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

Anchor
blob blob

Background Color
color #C3CDA1
Does DAS support datatypes like Blob?

RDB DAS supports SQL Data Types like Blob, Clob, ByteArray, Array.

Anchor
namedParams namedParams

Background Color
color #C3CDA1
Does DAS support named parameters passing?

User can do Command.setParameter(String name, Object value), getParameter(String name). Indexed set/getParameter() is available as before. Also <create>, <update>, <delete> from Config support named parameters.