You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Akhil Kumar <r1...@in.ibm.com> on 2003/08/25 13:26:24 UTC
#OJB201 (on Identity columns in db/2)
Hi,
This is a response to #OJB201...
(http://scarab.werken.com/issues/id/OJB201)
I had spent some time earlier on the approach suggested in this issue but
did not post it for the reason documented below
I thaught it'll be better that others also understand the implications (of
Identity Column based SeqMgr )
Platform.getLastInsertIdentity() should not be implemented as described in
the defect !
The db/2 scalar function 'identity_val_local() ' does not take any
parameter...
it is supposed to return the value of last identity column that was
incremented !
The reporter of the defect has recommended using
"select identity_val_local() from <tableName> fetch first ro only"
however the above SQL has nothing to do with the <tableName>..
running it is as good as running: "values identity_val_local()" which does
not take any table name.
and it can make the usage of "values identity_val_local()" : potentially
dangerous:
in the following scenario:
-Table T1 uses Identity column (and used in O-R mapping)
-A Trigger is defined for INSERTS in T1 which inserts a record in T2 (T2
has nothing to do with OR business)
(such approaches are there in many systems e.g. automatically
calculating summaries etc)
-both T1 and T2 use Identity columns.
-OJB inserts a record in T1 which leads to another record getting added to
T2
-"values identity_val_local()" will return the value of identity column in
T2 and not T1, as required by the native based SeqMgr.
thanks
akhil
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: More on Identity columns in db/2
Posted by Michael Becke <be...@u.washington.edu>.
Hi Akhil,
You have to specify the identity column as read-only. You can do this
by adding 'access="readonly"' to the field descriptor.
Mike
nntp://news.gmane.org/gmane.group.name wrote:
> I came back to this topic again and realised that INSERT statements in OJB
> are always
> trying to send the PK column also in the query.
> That being the case, How do we use "SequenceManagerNativeImpl" ?
> The two dbs that I know (SQLServer and db/2) do not allow u to pass the
> value for an Identity Column in SQL statement.
> Am I missing some thing ?
>
> TIA
> akhil
>
>
> "Akhil Kumar" <r1...@in.ibm.com> wrote in message
> news:OF88572F82.137C53AB-ON65256D8D.003F469C@in.ibm.com...
>
>>
>>
>>
>>Hi,
>>This is a response to #OJB201...
>>(http://scarab.werken.com/issues/id/OJB201)
>>I had spent some time earlier on the approach suggested in this issue but
>>did not post it for the reason documented below
>>I thaught it'll be better that others also understand the implications (of
>>Identity Column based SeqMgr )
>>
>>Platform.getLastInsertIdentity() should not be implemented as described in
>>the defect !
>>
>>The db/2 scalar function 'identity_val_local() ' does not take any
>>parameter...
>>it is supposed to return the value of last identity column that was
>>incremented !
>>The reporter of the defect has recommended using
>>"select identity_val_local() from <tableName> fetch first ro only"
>>however the above SQL has nothing to do with the <tableName>..
>>
>>running it is as good as running: "values identity_val_local()" which does
>>not take any table name.
>>and it can make the usage of "values identity_val_local()" : potentially
>>dangerous:
>>in the following scenario:
>>
>>-Table T1 uses Identity column (and used in O-R mapping)
>>-A Trigger is defined for INSERTS in T1 which inserts a record in T2 (T2
>>has nothing to do with OR business)
>> (such approaches are there in many systems e.g. automatically
>>calculating summaries etc)
>>-both T1 and T2 use Identity columns.
>>-OJB inserts a record in T1 which leads to another record getting added to
>>T2
>>-"values identity_val_local()" will return the value of identity column
>
> in
>
>>T2 and not T1, as required by the native based SeqMgr.
>>
>>thanks
>>akhil
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
More on Identity columns in db/2
Posted by "nntp://news.gmane.org/gmane.group.name" <r1...@in.ibm.com>.
I came back to this topic again and realised that INSERT statements in OJB
are always
trying to send the PK column also in the query.
That being the case, How do we use "SequenceManagerNativeImpl" ?
The two dbs that I know (SQLServer and db/2) do not allow u to pass the
value for an Identity Column in SQL statement.
Am I missing some thing ?
TIA
akhil
"Akhil Kumar" <r1...@in.ibm.com> wrote in message
news:OF88572F82.137C53AB-ON65256D8D.003F469C@in.ibm.com...
>
>
>
>
> Hi,
> This is a response to #OJB201...
> (http://scarab.werken.com/issues/id/OJB201)
> I had spent some time earlier on the approach suggested in this issue but
> did not post it for the reason documented below
> I thaught it'll be better that others also understand the implications (of
> Identity Column based SeqMgr )
>
> Platform.getLastInsertIdentity() should not be implemented as described in
> the defect !
>
> The db/2 scalar function 'identity_val_local() ' does not take any
> parameter...
> it is supposed to return the value of last identity column that was
> incremented !
> The reporter of the defect has recommended using
> "select identity_val_local() from <tableName> fetch first ro only"
> however the above SQL has nothing to do with the <tableName>..
>
> running it is as good as running: "values identity_val_local()" which does
> not take any table name.
> and it can make the usage of "values identity_val_local()" : potentially
> dangerous:
> in the following scenario:
>
> -Table T1 uses Identity column (and used in O-R mapping)
> -A Trigger is defined for INSERTS in T1 which inserts a record in T2 (T2
> has nothing to do with OR business)
> (such approaches are there in many systems e.g. automatically
> calculating summaries etc)
> -both T1 and T2 use Identity columns.
> -OJB inserts a record in T1 which leads to another record getting added to
> T2
> -"values identity_val_local()" will return the value of identity column
in
> T2 and not T1, as required by the native based SeqMgr.
>
> thanks
> akhil
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
More on Identity columns in db/2
Posted by "nntp://news.gmane.org/gmane.group.name" <r1...@in.ibm.com>.
I came back to this topic again and realised that INSERT statements in OJB
are always
trying to send the PK column also in the query.
That being the case, How do we use "SequenceManagerNativeImpl" ?
The two dbs that I know (SQLServer and db/2) do not allow u to pass the
value for an Identity Column in SQL statement.
Am I missing some thing ?
TIA
akhil
"Akhil Kumar" <r1...@in.ibm.com> wrote in message
news:OF88572F82.137C53AB-ON65256D8D.003F469C@in.ibm.com...
>
>
>
>
> Hi,
> This is a response to #OJB201...
> (http://scarab.werken.com/issues/id/OJB201)
> I had spent some time earlier on the approach suggested in this issue but
> did not post it for the reason documented below
> I thaught it'll be better that others also understand the implications (of
> Identity Column based SeqMgr )
>
> Platform.getLastInsertIdentity() should not be implemented as described in
> the defect !
>
> The db/2 scalar function 'identity_val_local() ' does not take any
> parameter...
> it is supposed to return the value of last identity column that was
> incremented !
> The reporter of the defect has recommended using
> "select identity_val_local() from <tableName> fetch first ro only"
> however the above SQL has nothing to do with the <tableName>..
>
> running it is as good as running: "values identity_val_local()" which does
> not take any table name.
> and it can make the usage of "values identity_val_local()" : potentially
> dangerous:
> in the following scenario:
>
> -Table T1 uses Identity column (and used in O-R mapping)
> -A Trigger is defined for INSERTS in T1 which inserts a record in T2 (T2
> has nothing to do with OR business)
> (such approaches are there in many systems e.g. automatically
> calculating summaries etc)
> -both T1 and T2 use Identity columns.
> -OJB inserts a record in T1 which leads to another record getting added to
> T2
> -"values identity_val_local()" will return the value of identity column
in
> T2 and not T1, as required by the native based SeqMgr.
>
> thanks
> akhil
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Mapping Tutorial Take 1
Posted by Brian McCallister <mc...@forthillcompany.com>.
FYI:
I am working on a set of tutorials to take the place of the current PB
and ODMG tutorials (though it will probably expand to the JDO as the
JDO depends on the PB). I will likely add one more which steps through
a relation as a lot of questions still come up on the list about the
exact relations semantics. It is definitely newbie oriented, but should
be sufficient, when finished, for people to dive into more advanced
stuff without any pain.
-Brian
On Thursday, August 28, 2003, at 03:09 PM, Antonio Gallardo wrote:
> Brian McCallister dijo:
>> Any reviews, comments, etc on the initial draft of the mapping
>> tutorial
>> are appreciated:
>>
>> http://fischer.skife.org/ojb/mapping-tutorial.html
>
> I think it is OK. It is simple and offer a good startup for newbies.
>
> Antonio Gallardo
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Mapping Tutorial Take 1
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Brian McCallister dijo:
> Any reviews, comments, etc on the initial draft of the mapping tutorial
> are appreciated:
>
> http://fischer.skife.org/ojb/mapping-tutorial.html
I think it is OK. It is simple and offer a good startup for newbies.
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: #OJB201 (on Identity columns in db/2)
Posted by "nntp://news.gmane.org/gmane.group.name" <r1...@in.ibm.com>.
Hello Mike,
your understanding is correct.
Trigger'ed INSERT was the only scenario I could think of on top of my head.
But in general if there is any other scenario where more than one Identity
columns
are inserted before you call "values identity_val_local()" u'll face the
issue.
However this behaviour is local to a connection, so identity column INSERTS
done
on different connections do not come on the way of each other.
Which is the basic isolation property of database connection.
-akhil
"Michael Becke" <be...@u.washington.edu> wrote in message
news:CBF7E208-D7BD-11D7-A328-00306557E112@u.washington.edu...
> Hello Akhil,
>
> Thank you for chiming in on this issue. This is something I was not
> aware of. So, just to make sure I understand what you are saying, the
> SeqMgr:
>
> - should not use the table name when getting the identity value to
> avoid being misleading
> - should not be used on tables that trigger other table inserts
>
> Is this correct?
>
> Mike
>
> On Monday, August 25, 2003, at 07:26 AM, Akhil Kumar wrote:
> >
> >
> > Hi,
> > This is a response to #OJB201...
> > (http://scarab.werken.com/issues/id/OJB201)
> > I had spent some time earlier on the approach suggested in this issue
> > but
> > did not post it for the reason documented below
> > I thaught it'll be better that others also understand the implications
> > (of
> > Identity Column based SeqMgr )
> >
> > Platform.getLastInsertIdentity() should not be implemented as
> > described in
> > the defect !
> >
> > The db/2 scalar function 'identity_val_local() ' does not take any
> > parameter...
> > it is supposed to return the value of last identity column that was
> > incremented !
> > The reporter of the defect has recommended using
> > "select identity_val_local() from <tableName> fetch first ro only"
> > however the above SQL has nothing to do with the <tableName>..
> >
> > running it is as good as running: "values identity_val_local()" which
> > does
> > not take any table name.
> > and it can make the usage of "values identity_val_local()" :
> > potentially
> > dangerous:
> > in the following scenario:
> >
> > -Table T1 uses Identity column (and used in O-R mapping)
> > -A Trigger is defined for INSERTS in T1 which inserts a record in T2
> > (T2
> > has nothing to do with OR business)
> > (such approaches are there in many systems e.g. automatically
> > calculating summaries etc)
> > -both T1 and T2 use Identity columns.
> > -OJB inserts a record in T1 which leads to another record getting
> > added to
> > T2
> > -"values identity_val_local()" will return the value of identity
> > column in
> > T2 and not T1, as required by the native based SeqMgr.
> >
> > thanks
> > akhil
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-user-help@db.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: #OJB201 (on Identity columns in db/2)
Posted by Michael Becke <be...@u.washington.edu>.
Hello Akhil,
Thank you for chiming in on this issue. This is something I was not
aware of. So, just to make sure I understand what you are saying, the
SeqMgr:
- should not use the table name when getting the identity value to
avoid being misleading
- should not be used on tables that trigger other table inserts
Is this correct?
Mike
On Monday, August 25, 2003, at 07:26 AM, Akhil Kumar wrote:
>
>
> Hi,
> This is a response to #OJB201...
> (http://scarab.werken.com/issues/id/OJB201)
> I had spent some time earlier on the approach suggested in this issue
> but
> did not post it for the reason documented below
> I thaught it'll be better that others also understand the implications
> (of
> Identity Column based SeqMgr )
>
> Platform.getLastInsertIdentity() should not be implemented as
> described in
> the defect !
>
> The db/2 scalar function 'identity_val_local() ' does not take any
> parameter...
> it is supposed to return the value of last identity column that was
> incremented !
> The reporter of the defect has recommended using
> "select identity_val_local() from <tableName> fetch first ro only"
> however the above SQL has nothing to do with the <tableName>..
>
> running it is as good as running: "values identity_val_local()" which
> does
> not take any table name.
> and it can make the usage of "values identity_val_local()" :
> potentially
> dangerous:
> in the following scenario:
>
> -Table T1 uses Identity column (and used in O-R mapping)
> -A Trigger is defined for INSERTS in T1 which inserts a record in T2
> (T2
> has nothing to do with OR business)
> (such approaches are there in many systems e.g. automatically
> calculating summaries etc)
> -both T1 and T2 use Identity columns.
> -OJB inserts a record in T1 which leads to another record getting
> added to
> T2
> -"values identity_val_local()" will return the value of identity
> column in
> T2 and not T1, as required by the native based SeqMgr.
>
> thanks
> akhil
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Mapping Tutorial Take 1
Posted by Thomas Mahler <th...@web.de>.
hi again,
Brian McCallister wrote:
>> 1. with the latest cvs head the jdbc-type attribute is now optional.
>> If no type is specified, OJB tries to deduce a proper type from the
>> Java type of the persistent field.
>>
>
> Excellent, I had thought it should be able to do this. It will be in for
> 1.0 I presume?
yes.
>
>> 2. I'd prefer to see some more detail on the overall structure of the
>> repository.xml and the include mechanism. (As I did it in the
>> tutorial1.html). But maybe you approach is better as it liberates the
>> user from too much knowledge about internal things?
>>
>
> I agree completely that the repository.xml needs a thorough explanation
> - I also think that the explanation should be orthogonal to using the
> various API's however.
+1 (there are only very few API dependend things with the repository.
Setting a isolation level only makes sense for ODMG, auto-update and
auto-delete have different semantics for ODMG and PB)
>> 3. In the advanced topics section we should also mention mapping of
>> inheritance hierarchies and polymorphism and link to tutorial3.
>>
>
> Good call, will do.
>
>>
>> The next question I have is where to place your tutorials. I think
>> both tutorials together are a good replacement of my initial
>> tutorial1.html.
>>
>> The only problem is that tutorial2 and 4 still rely on the
>> presentation of the use cases from tutorial1. So this stuff must be
>> moved to tutorial2, or tut2 and tut4 have to be rewritten too.
>> What do you think?
>
>
> Replacing tutorial2 is planned,
cool!
> and replacing tutorial1 also requires
> replacing tutorial4. Making use of JDO requires a lot more information
> than tutorial4 actually gives, however.
you're right. in it's current form tut4 is only a getting started text
for the demo JDO demo application.
> I am not sure the best way to
> tackle this, so am still thinking about it.
Maybe we should not put too much energy in tut4 until the JDO solution
has matured a bit.
> There is a lot of gray area
> around the OJB+JDORI solution
+1
(.jdo vs repository.xml not being the
> least an xslt to generate .jdo's from the repository.xml might not be a
> bad idea down the line -- assuming OJB will pull metadata from either
> source eventually).
To be 100% JDO compliant a JDO file is mandatory. So the most natural
solution for a JDO implementation is to keep the metadata in JDO file(s).
At some point in time the OJB repository persistor will be able to read
a repository.jdo file (enhanced with OJB vendor extensions) and to build
up the OJB repository from this file.
Of course it can be helpful to have an xslt to generate repository.jdo
files from repository.xml.
Thomas
>
> -Brian
>
>>
>> cheers,
>> Thomas
>>
>>> -Brian
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Mapping Tutorial Take 1
Posted by Brian McCallister <mc...@forthillcompany.com>.
> 1. with the latest cvs head the jdbc-type attribute is now optional.
> If no type is specified, OJB tries to deduce a proper type from the
> Java type of the persistent field.
>
Excellent, I had thought it should be able to do this. It will be in
for 1.0 I presume?
> 2. I'd prefer to see some more detail on the overall structure of the
> repository.xml and the include mechanism. (As I did it in the
> tutorial1.html). But maybe you approach is better as it liberates the
> user from too much knowledge about internal things?
>
I agree completely that the repository.xml needs a thorough explanation
- I also think that the explanation should be orthogonal to using the
various API's however.
> 3. In the advanced topics section we should also mention mapping of
> inheritance hierarchies and polymorphism and link to tutorial3.
>
Good call, will do.
>
> The next question I have is where to place your tutorials. I think
> both tutorials together are a good replacement of my initial
> tutorial1.html.
>
> The only problem is that tutorial2 and 4 still rely on the
> presentation of the use cases from tutorial1. So this stuff must be
> moved to tutorial2, or tut2 and tut4 have to be rewritten too.
> What do you think?
Replacing tutorial2 is planned, and replacing tutorial1 also requires
replacing tutorial4. Making use of JDO requires a lot more information
than tutorial4 actually gives, however. I am not sure the best way to
tackle this, so am still thinking about it. There is a lot of gray area
around the OJB+JDORI solution (.jdo vs repository.xml not being the
least an xslt to generate .jdo's from the repository.xml might not be a
bad idea down the line -- assuming OJB will pull metadata from either
source eventually).
-Brian
>
> cheers,
> Thomas
>
>> -Brian
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Mapping Tutorial Take 1
Posted by Thomas Mahler <th...@web.de>.
Hi Brian,
Brian McCallister wrote:
> Any reviews, comments, etc on the initial draft of the mapping tutorial
> are appreciated:
>
> http://fischer.skife.org/ojb/mapping-tutorial.html
>
> I do not have as much confidence in this as I do in the pb-tutorial
>
> ( which current version is at...
> http://fischer.skife.org/ojb/pb-tutorial.html -- It is only one typo and
> a link added from the cvs version)
>
> Thank you in advance! I am *not* confident that the one I just posted is
> the best approach, it reads a bit to dry (okay, so O/R mapping metadata
> isn't exactly exciting most of the time, but reading it should be quick
> and easy if it is simple, and this is fairly simple.
I like both your tutorials, the pb-tutorial and the mapping-tutorial as
well.
I've only some remarks to the mapping tutorial:
1. with the latest cvs head the jdbc-type attribute is now optional. If
no type is specified, OJB tries to deduce a proper type from the Java
type of the persistent field.
2. I'd prefer to see some more detail on the overall structure of the
repository.xml and the include mechanism. (As I did it in the
tutorial1.html). But maybe you approach is better as it liberates the
user from too much knowledge about internal things?
3. In the advanced topics section we should also mention mapping of
inheritance hierarchies and polymorphism and link to tutorial3.
The next question I have is where to place your tutorials. I think both
tutorials together are a good replacement of my initial tutorial1.html.
The only problem is that tutorial2 and 4 still rely on the presentation
of the use cases from tutorial1. So this stuff must be moved to
tutorial2, or tut2 and tut4 have to be rewritten too.
What do you think?
cheers,
Thomas
>
> -Brian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Mapping Tutorial Take 1
Posted by Brian McCallister <mc...@forthillcompany.com>.
Any reviews, comments, etc on the initial draft of the mapping tutorial
are appreciated:
http://fischer.skife.org/ojb/mapping-tutorial.html
I do not have as much confidence in this as I do in the pb-tutorial
( which current version is at...
http://fischer.skife.org/ojb/pb-tutorial.html -- It is only one typo
and a link added from the cvs version)
Thank you in advance! I am *not* confident that the one I just posted
is the best approach, it reads a bit to dry (okay, so O/R mapping
metadata isn't exactly exciting most of the time, but reading it should
be quick and easy if it is simple, and this is fairly simple.
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org