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

Wiki Markup
{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.

Anchor
Migration from M2 Migration from M2

Wiki Markup
{bgcolor:#C3CDA1}Migration from M2{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

".

Anchor
transaction management transaction management

Wiki Markup
{bgcolor:#C3CDA1}Handling internal/external transaction management{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.

Anchor
handling parent/child relationship handling parent/child

relationship

Wiki Markup
{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,

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

Wiki Markup
{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.

Anchor
no PK defined no PK defined

Wiki Markup
{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.

Having

PK

ensures

uniqueness

of

Data

Object

-

returned

as

query

result.

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

Wiki Markup
{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.

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

Wiki Markup
{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

.

Anchor
Optimistic Concurrency Control Optimistic Concurrency Control

Wiki Markup
{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.

Anchor
keyRestricted keyRestricted

Wiki Markup
{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'.

Anchor
paging paging

Wiki Markup
{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

).

Anchor
ResultSet ResultSet

Wiki Markup
{bgcolor:#C3CDA1} Example to define the ResultSet shape Definition for a join in DAS{bgcolor}

Doing:

}
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

Wiki Markup
{bgcolor:#C3CDA1}Does DAS support datatypes like Blob? {bgcolor}

RDB

DAS

supports

SQL

Data

Types

like

Blob,

Clob,

ByteArray,

Array.

Anchor
namedParams namedParams

Wiki Markup
{bgcolor:#C3CDA1} Does DAS support named parameters passing?{bgcolor}

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.