Objects in the OR-Database
Malte Finsterwalder
OO Software uses interacting Objects to privide functionality.
Object Relational Databases (like DB2) handle objects too.
In the database I can create User Defined Types (UDTs) that can then
be used as column- or table types. I can create, store and retrieve
objects from the database tables.
The access to these database objects is through SQL.
SQL is a declerative language.
Object interaction is imperative.
An object interaction might look something like:
1) create or load an object o1
2) create or load another object o2
3) call method m on o2 and pass o1 as parameter: o2.m(o1)
4) method m may modify o2 and may also call modifying methods on o1
4) persist the changes in o1 and o2
Is this type of interaction possible inside an OR-Database?
Greetings,
Malte
Dirk Wollscheid
> Hi there,
>
> OO Software uses interacting Objects to privide functionality.
>
> Object Relational Databases (like DB2) handle objects too.
>
> In the database I can create User Defined Types (UDTs) that can then
> be used as column- or table types. I can create, store and retrieve
> objects from the database tables.
>
> The access to these database objects is through SQL.
> SQL is a declerative language.
>
> Object interaction is imperative.
SQL has procedural language constructs. They're imperative IMO.
> An object interaction might look something like:
>
> 1) create or load an object o1
> 2) create or load another object o2
This would be an "INSERT" or SELECT
> 3) call method m on o2 and pass o1 as parameter: o2.m(o1)
This would be a SQL method call
> 4) method m may modify o2 and may also call modifying methods on o1
This is not problem either - I think
> 4) persist the changes in o1 and o2
UPDATE
> Is this type of interaction possible inside an OR-Database?
Yes, I think most of this is possible in DB2 right now or in "a future
version". DB2 has insert/update/select objects , SQL methods that can
call other methods.
You could put the stuff in 1-4 in an SP and run it "inside an
O-R-Database".
Does that answer your question?
Dirk
Malte Finsterwalder
>SQL has procedural language constructs. They're imperative IMO.
You are right, I found some.
I was mislead by just looking at SQL queries for the moment.
>> An object interaction might look something like:
>>
>> 1) create or load an object o1
>> 2) create or load another object o2
>
>This would be an "INSERT" or SELECT
>
>> 3) call method m on o2 and pass o1 as parameter: o2.m(o1)
>
>This would be a SQL method call
>
>> 4) method m may modify o2 and may also call modifying methods on o1
>
>This is not problem either - I think
>
>> 4) persist the changes in o1 and o2
>
>UPDATE
>
>> Is this type of interaction possible inside an OR-Database?
>
>Yes, I think most of this is possible in DB2 right now or in "a future
>version". DB2 has insert/update/select objects , SQL methods that can
>call other methods.
>
>You could put the stuff in 1-4 in an SP and run it "inside an
>O-R-Database".
>
>Does that answer your question?
Partially.
I see how I can use an SP to combine the steps.
Can I create a variable in a SQL SP with a UDT type?
Can I select an object from a table into such a variable?
Can I then call a method on this variable and pass another variable
that holds another object?
How can I make use of the result of the method?
Do you have any example?
Is it also possible to do this in a combined SQL command that I can
execute from JDBC for example, so I don't have to write an SP first?
Greetings,
Malte
Serge Rielau
"copy-semantics".
This means that although a method can return "self as result" it is really
copy of self.
As an example
CREATE TYPE a AS (x INT) MODE DB2SQL%
CREATE TABLE T(c1 a)%
BEGIN ATOMIC
DECLARE var a;
SET a = a();
VALUES a..x(5);
INSERT INTO T VALUES x;
END%
SELECT a..x FROM T%
=> NULL
a..x(5) did not change a in place.
SET a = a..x(5) would have been required.
or
SET a = a()..x(5)
Cheers
Serge
--
Serge Rielau
DB2 UDB SQL Compiler Development
IBM Software Lab, Canada
Serge Rielau
SQL Procedures to not support UDTs (distinct and structured) in V7.
You can use those types within statements, but you cannot declare variables
or pass argumenst of those types.
In embedded there is upport for structured types in combination with
transform functions.
SQL Functions (and of course methods) to support all DB2 datatypes
(including UDT)
See my example in my other post in this thread for procedural logic outside
procedures.
Malte Finsterwalder
>One interesting factum with methods in SQL is that the standard defines
>"copy-semantics".
>This means that although a method can return "self as result" it is really
>copy of self.
>As an example
>
>CREATE TYPE a AS (x INT) MODE DB2SQL%
>CREATE TABLE T(c1 a)%
>
>BEGIN ATOMIC
> DECLARE var a;
> SET a = a();
> VALUES a..x(5);
Why do you need VALUES here? What does it do?
> INSERT INTO T VALUES x;
is this correct, or should it be:
INSERT INTO T VALUES _a_; ?
This helped a lot.
Greetings,
Malte
Serge Rielau
BEGIN ATOMIC
DECLARE var a;
SET var = a();
VALUES var..x(5);
INSERT INTO T VALUES var;
END
Now given that corrected version:
No values doesn't do a thing because it does not have the side effect to change
var. It changes a copy of var whoich goes to nowhere-land. Thus the an empty
instance (a()) will be inserted, which is what I tried, but failed to show.
Dirk Wollscheid
Serge mentioned all of the restrictions we have right now.
> Is it also possible to do this in a combined SQL command that I can
> execute from JDBC for example, so I don't have to write an SP first?
Serge's example should work from JDBC too.
Dirk