Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Legacy and Oracle.
[CDO] Legacy and Oracle. [message #428410] Fri, 20 March 2009 14:11 Go to next message
Guillaume Brocard is currently offline Guillaume BrocardFriend
Messages: 25
Registered: July 2009
Junior Member
Hi,

It's been several weeks now trying to persist an ugly model in a database,
so as to achieve collaboration and configuration management upon this
model.
We failed to do so with Teneo (our first choice, the application runs upon
Eclipse 3.3 platform). In a desperate attempt, we decided to switch to
Eclipse 3.5 and gave CDO 2.0.0M5 a try.

Since we cannot rewrite the whole application, we are sticking with the
core M2 (already pretty ugly), which is re-generated, using CDO importer.
Quite wonderfully (and impressively), everything works fine and fast using
CDO.

We have tried several stores, from memory to mysql, and finally elected
hsqldb. But we are strongly asked to use Oracle. My first question then :
is there anyone out there contributing an Oracle dbAdapter ?

Now we would also like to test the application using the core M2. It comes
with a new M2, that, once instantiated, references models from our core
M2. Of course, this new M2 ain't generated by us (that would be far too
simple). Up to my second question (a multiple one, sorry ;)): how about
legacy support in CDO ? Should we wait for the official release (in June I
assume), or can we test this already (and how ?) ?

Thanks,
Guillaume.
Re: [CDO] Legacy and Oracle. [message #428416 is a reply to message #428410] Fri, 20 March 2009 15:14 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Guillaume ,

comments below

> We have tried several stores, from memory to mysql, and finally elected
> hsqldb. But we are strongly asked to use Oracle. My first question then
> : is there anyone out there contributing an Oracle dbAdapter ?

No there isn't, but it's fairly easy to implement one, I believe. I did
postresql adapter myself, and did took me a couple of hours to do so. If
you are willing to implement it, don't hesitate asking here! And, of
course, contributions will be welcome :)

> Now we would also like to test the application using the core M2. It
> comes with a new M2, that, once instantiated, references models from our
> core M2. Of course, this new M2 ain't generated by us (that would be far
> too simple). Up to my second question (a multiple one, sorry ;)): how
> about legacy support in CDO ? Should we wait for the official release
> (in June I assume), or can we test this already (and how ?) ?

As of M6, legacy is not yet implemented. We are currently waiting for
some new EMF 2.5.0 features to come in. Take a look at:

Provide vetoable notification for read and write access
https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130

I can't give you an estimation right now regarding its availability, but
yes, it will be ready for June :)

> Thanks,
> Guillaume.

you are welcome!
Re: [CDO] Legacy and Oracle. [message #428418 is a reply to message #428416] Fri, 20 March 2009 15:57 Go to previous messageGo to next message
Guillaume Brocard is currently offline Guillaume BrocardFriend
Messages: 25
Registered: July 2009
Junior Member
Victor,

comments below.

Víctor Roldán Betancort wrote:

> Guillaume ,

> comments below

>> We have tried several stores, from memory to mysql, and finally elected
>> hsqldb. But we are strongly asked to use Oracle. My first question then
>> : is there anyone out there contributing an Oracle dbAdapter ?

> No there isn't, but it's fairly easy to implement one, I believe. I did
> postresql adapter myself, and did took me a couple of hours to do so. If
> you are willing to implement it, don't hesitate asking here! And, of
> course, contributions will be welcome :)


I am willing, as this is the recommanded db in my group, but I'm not sure
that this is this simple. For instance, Oracle names can't exceed 30
characters. Worst, a constraint (e.g. foreign key) must have a unique
name, whatever the table. I know this has more to do with mapping
strategies. Thus I would have to implement both to get it to work.
Anyway, I'll give it a try, but I can't tell you when exactly, for I need
to focus on the other functionnalities now (and I may be able to kick
Oracle out of the game later).


>> Now we would also like to test the application using the core M2. It
>> comes with a new M2, that, once instantiated, references models from our
>> core M2. Of course, this new M2 ain't generated by us (that would be far
>> too simple). Up to my second question (a multiple one, sorry ;)): how
>> about legacy support in CDO ? Should we wait for the official release
>> (in June I assume), or can we test this already (and how ?) ?

> As of M6, legacy is not yet implemented. We are currently waiting for
> some new EMF 2.5.0 features to come in. Take a look at:

> Provide vetoable notification for read and write access
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130

I don't quite see how it would help implement legacy.
I mean surely newly generated models could take advantage of this feature,
but what about already existing ones ?

> I can't give you an estimation right now regarding its availability, but
> yes, it will be ready for June :)

Perfect !

>> Thanks,
>> Guillaume.

> you are welcome!

Again, thanks for your answers.
Re: [CDO] Legacy and Oracle. [message #428460 is a reply to message #428418] Mon, 23 March 2009 11:42 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Guillaume,

comments below

>>> We have tried several stores, from memory to mysql, and finally
>>> elected hsqldb. But we are strongly asked to use Oracle. My first
>>> question then : is there anyone out there contributing an Oracle
>>> dbAdapter ?
>
>> No there isn't, but it's fairly easy to implement one, I believe. I
>> did postresql adapter myself, and did took me a couple of hours to do
>> so. If you are willing to implement it, don't hesitate asking here!
>> And, of course, contributions will be welcome :)
>
>
> I am willing, as this is the recommanded db in my group, but I'm not
> sure that this is this simple. For instance, Oracle names can't exceed
> 30 characters. Worst, a constraint (e.g. foreign key) must have a unique
> name, whatever the table. I know this has more to do with mapping
> strategies. Thus I would have to implement both to get it to work.
> Anyway, I'll give it a try, but I can't tell you when exactly, for I
> need to focus on the other functionnalities now (and I may be able to
> kick Oracle out of the game later).

Having an Oracle DBAdapter was always in the plans of the CDO project,
but somehow left a bit aside, since there are still many more important
issues to tackle.

I suspect both those two issues you point out can be managed at
DBAdapter level, so you *shouldn't* need to implement any mapping
strategy. For instance, for the index contraint, you might override
org.eclipse.net4j.spi.db.DBAdapter.createIndex(IDBIndex, Statement, int)
to fulfill Oracle peculiarities.

In case it is really necessary, I think we should analyze your
requirements and see whether they fit in the current design, so we can
reach to some compromise in our default implementation and avoiding
implementing your own mapping strategy. CDO should stay generic enough
to give support to any JDBC compatible RDBMS. OODBMS are a complete
different story :P

>>> Now we would also like to test the application using the core M2. It
>>> comes with a new M2, that, once instantiated, references models from
>>> our core M2. Of course, this new M2 ain't generated by us (that would
>>> be far too simple). Up to my second question (a multiple one, sorry
>>> ;)): how about legacy support in CDO ? Should we wait for the
>>> official release (in June I assume), or can we test this already (and
>>> how ?) ?
>
>> As of M6, legacy is not yet implemented. We are currently waiting for
>> some new EMF 2.5.0 features to come in. Take a look at:
>
>> Provide vetoable notification for read and write access
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130
>
> I don't quite see how it would help implement legacy.
> I mean surely newly generated models could take advantage of this
> feature, but what about already existing ones ?

Me neither xD But according to Eike, it does :P I believe this is just
one of the necessary requirements, there are still issues to overcome...
Eike can probably say more about this, but unfortunately (for us that
are not there :P) he's now at EclipseCon.

Maybe Ed knows a bit of Eike's plans?

Cheers,
ViK.
Re: [CDO] Legacy and Oracle. [message #428484 is a reply to message #428410] Mon, 23 March 2009 17:47 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Guillaume,

Coments below...


Guillaume Brocard schrieb:
> Hi,
>
> It's been several weeks now trying to persist an ugly model in a
> database,
Ugly models should be persisted in the waste paper basket :P

> so as to achieve collaboration and configuration management upon this
> model.
> We failed to do so with Teneo (our first choice, the application runs
> upon Eclipse 3.3 platform). In a desperate attempt, we decided to
> switch to Eclipse 3.5 and gave CDO 2.0.0M5 a try.
>
> Since we cannot rewrite the whole application, we are sticking with
> the core M2 (already pretty ugly), which is re-generated, using CDO
> importer.
> Quite wonderfully (and impressively), everything works fine and fast
> using CDO.
>
> We have tried several stores, from memory to mysql, and finally
> elected hsqldb. But we are strongly asked to use Oracle. My first
> question then : is there anyone out there contributing an Oracle
> dbAdapter ?
Why don't you do it? It's just so easy!

>
> Now we would also like to test the application using the core M2. It
> comes with a new M2, that, once instantiated, references models from
> our core M2. Of course, this new M2 ain't generated by us (that would
> be far too simple). Up to my second question (a multiple one, sorry
> ;)): how about legacy support in CDO ? Should we wait for the official
> release (in June I assume), or can we test this already (and how ?) ?
Are you referring to the MOF pyramid terminology by saing M2? Or a
milestone?
Unfortunately all the legacy support stuff got dramatically delayed due
to a personal desaster of a team member. At this very moment I even
can't promise that it will make it to 2.0 GA ;-(

Cheers
/Eike

----
http://thegordian.blogspot.com


>
> Thanks,
> Guillaume.
>


Re: [CDO] Legacy and Oracle. [message #428485 is a reply to message #428460] Mon, 23 March 2009 17:53 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Guys,

The EMF vetoable listener support bugzilla is indeed the central enabler
for CDO legacy model support because it provides means to intercept all
read and write access to arbitrary (here: legacy) model objects. This is
needed to acquire read and write locks which, in turn, trigger demand
loading and so on...

There is also a CDO bugzilla about legacy model support. I can't recall
the id but it's blocked by the mentioned EMF bug.

Cheers
/Eike

----
http://thegordian.blogspot.com



Víctor Roldán Betancort schrieb:
> Guillaume,
>
> comments below
>
>>>> We have tried several stores, from memory to mysql, and finally
>>>> elected hsqldb. But we are strongly asked to use Oracle. My first
>>>> question then : is there anyone out there contributing an Oracle
>>>> dbAdapter ?
>>
>>> No there isn't, but it's fairly easy to implement one, I believe. I
>>> did postresql adapter myself, and did took me a couple of hours to
>>> do so. If you are willing to implement it, don't hesitate asking
>>> here! And, of course, contributions will be welcome :)
>>
>>
>> I am willing, as this is the recommanded db in my group, but I'm not
>> sure that this is this simple. For instance, Oracle names can't
>> exceed 30 characters. Worst, a constraint (e.g. foreign key) must
>> have a unique name, whatever the table. I know this has more to do
>> with mapping strategies. Thus I would have to implement both to get
>> it to work.
>> Anyway, I'll give it a try, but I can't tell you when exactly, for I
>> need to focus on the other functionnalities now (and I may be able to
>> kick Oracle out of the game later).
>
> Having an Oracle DBAdapter was always in the plans of the CDO project,
> but somehow left a bit aside, since there are still many more
> important issues to tackle.
>
> I suspect both those two issues you point out can be managed at
> DBAdapter level, so you *shouldn't* need to implement any mapping
> strategy. For instance, for the index contraint, you might override
> org.eclipse.net4j.spi.db.DBAdapter.createIndex(IDBIndex, Statement,
> int) to fulfill Oracle peculiarities.
>
> In case it is really necessary, I think we should analyze your
> requirements and see whether they fit in the current design, so we can
> reach to some compromise in our default implementation and avoiding
> implementing your own mapping strategy. CDO should stay generic enough
> to give support to any JDBC compatible RDBMS. OODBMS are a complete
> different story :P
>
>>>> Now we would also like to test the application using the core M2.
>>>> It comes with a new M2, that, once instantiated, references models
>>>> from our core M2. Of course, this new M2 ain't generated by us
>>>> (that would be far too simple). Up to my second question (a
>>>> multiple one, sorry ;)): how about legacy support in CDO ? Should
>>>> we wait for the official release (in June I assume), or can we test
>>>> this already (and how ?) ?
>>
>>> As of M6, legacy is not yet implemented. We are currently waiting
>>> for some new EMF 2.5.0 features to come in. Take a look at:
>>
>>> Provide vetoable notification for read and write access
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130
>>
>> I don't quite see how it would help implement legacy.
>> I mean surely newly generated models could take advantage of this
>> feature, but what about already existing ones ?
>
> Me neither xD But according to Eike, it does :P I believe this is just
> one of the necessary requirements, there are still issues to overcome...
> Eike can probably say more about this, but unfortunately (for us that
> are not there :P) he's now at EclipseCon.
>
> Maybe Ed knows a bit of Eike's plans?
>
> Cheers,
> ViK.


Re: [CDO] Legacy and Oracle. [message #428498 is a reply to message #428485] Tue, 24 March 2009 08:44 Go to previous messageGo to next message
Guillaume Brocard is currently offline Guillaume BrocardFriend
Messages: 25
Registered: July 2009
Junior Member
Hi,

Victor, thanks for your answers.
As soon as I try to connect to Oracle, I'll let you know with the issues.

Eike, comments below.

Cheers,
Guillaume.

Eike Stepper wrote:

> Guys,

> The EMF vetoable listener support bugzilla is indeed the central enabler
> for CDO legacy model support because it provides means to intercept all
> read and write access to arbitrary (here: legacy) model objects. This is
> needed to acquire read and write locks which, in turn, trigger demand
> loading and so on...


I still don't quite see how models that have been generated out of this
scope will benefit from this feature. I mean those models don't even have
the preGet/Set vetoable abilities (you can even think about 2.3 or 2.4 EMF
models), so I'm a bit confused about their use, and then about the
"legacy" meaning. With Aspect-J I could think of a way to enable legacy
(using some preGet/Set pointcuts), but that does not seem to be the case
anymore (as of CDO 2.0 at least).


> There is also a CDO bugzilla about legacy model support. I can't recall
> the id but it's blocked by the mentioned EMF bug.

> Cheers
> /Eike

> ----
> http://thegordian.blogspot.com



> Víctor Roldán Betancort schrieb:
>> Guillaume,
>>
>> comments below
>>
>>>>> We have tried several stores, from memory to mysql, and finally
>>>>> elected hsqldb. But we are strongly asked to use Oracle. My first
>>>>> question then : is there anyone out there contributing an Oracle
>>>>> dbAdapter ?
>>>
>>>> No there isn't, but it's fairly easy to implement one, I believe. I
>>>> did postresql adapter myself, and did took me a couple of hours to
>>>> do so. If you are willing to implement it, don't hesitate asking
>>>> here! And, of course, contributions will be welcome :)
>>>
>>>
>>> I am willing, as this is the recommanded db in my group, but I'm not
>>> sure that this is this simple. For instance, Oracle names can't
>>> exceed 30 characters. Worst, a constraint (e.g. foreign key) must
>>> have a unique name, whatever the table. I know this has more to do
>>> with mapping strategies. Thus I would have to implement both to get
>>> it to work.
>>> Anyway, I'll give it a try, but I can't tell you when exactly, for I
>>> need to focus on the other functionnalities now (and I may be able to
>>> kick Oracle out of the game later).
>>
>> Having an Oracle DBAdapter was always in the plans of the CDO project,
>> but somehow left a bit aside, since there are still many more
>> important issues to tackle.
>>
>> I suspect both those two issues you point out can be managed at
>> DBAdapter level, so you *shouldn't* need to implement any mapping
>> strategy. For instance, for the index contraint, you might override
>> org.eclipse.net4j.spi.db.DBAdapter.createIndex(IDBIndex, Statement,
>> int) to fulfill Oracle peculiarities.
>>
>> In case it is really necessary, I think we should analyze your
>> requirements and see whether they fit in the current design, so we can
>> reach to some compromise in our default implementation and avoiding
>> implementing your own mapping strategy. CDO should stay generic enough
>> to give support to any JDBC compatible RDBMS. OODBMS are a complete
>> different story :P
>>
>>>>> Now we would also like to test the application using the core M2.
>>>>> It comes with a new M2, that, once instantiated, references models
>>>>> from our core M2. Of course, this new M2 ain't generated by us
>>>>> (that would be far too simple). Up to my second question (a
>>>>> multiple one, sorry ;)): how about legacy support in CDO ? Should
>>>>> we wait for the official release (in June I assume), or can we test
>>>>> this already (and how ?) ?
>>>
>>>> As of M6, legacy is not yet implemented. We are currently waiting
>>>> for some new EMF 2.5.0 features to come in. Take a look at:
>>>
>>>> Provide vetoable notification for read and write access
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130
>>>
>>> I don't quite see how it would help implement legacy.
>>> I mean surely newly generated models could take advantage of this
>>> feature, but what about already existing ones ?
>>
>> Me neither xD But according to Eike, it does :P I believe this is just
>> one of the necessary requirements, there are still issues to overcome...
>> Eike can probably say more about this, but unfortunately (for us that
>> are not there :P) he's now at EclipseCon.
>>
>> Maybe Ed knows a bit of Eike's plans?
>>
>> Cheers,
>> ViK.
Re: [CDO] Legacy and Oracle. [message #428499 is a reply to message #428484] Tue, 24 March 2009 08:55 Go to previous messageGo to next message
Guillaume Brocard is currently offline Guillaume BrocardFriend
Messages: 25
Registered: July 2009
Junior Member
Eike,

comments below.
Plus : maybe we should stick to the initial branch of this thread ;).

Guillaume.

Eike Stepper wrote:

> Guillaume,

> Coments below...


> Guillaume Brocard schrieb:
>> Hi,
>>
>> It's been several weeks now trying to persist an ugly model in a
>> database,
> Ugly models should be persisted in the waste paper basket :P


I wish I could do that ;)


>> so as to achieve collaboration and configuration management upon this
>> model.
>> We failed to do so with Teneo (our first choice, the application runs
>> upon Eclipse 3.3 platform). In a desperate attempt, we decided to
>> switch to Eclipse 3.5 and gave CDO 2.0.0M5 a try.
>>
>> Since we cannot rewrite the whole application, we are sticking with
>> the core M2 (already pretty ugly), which is re-generated, using CDO
>> importer.
>> Quite wonderfully (and impressively), everything works fine and fast
>> using CDO.
>>
>> We have tried several stores, from memory to mysql, and finally
>> elected hsqldb. But we are strongly asked to use Oracle. My first
>> question then : is there anyone out there contributing an Oracle
>> dbAdapter ?
> Why don't you do it? It's just so easy!


Yep, Victor answered my questions and I have been giving my thoughts on
the other branch (for now).


>>
>> Now we would also like to test the application using the core M2. It
>> comes with a new M2, that, once instantiated, references models from
>> our core M2. Of course, this new M2 ain't generated by us (that would
>> be far too simple). Up to my second question (a multiple one, sorry
>> ;)): how about legacy support in CDO ? Should we wait for the official
>> release (in June I assume), or can we test this already (and how ?) ?
> Are you referring to the MOF pyramid terminology by saing M2? Or a
> milestone?


I simply meant Meta-Model, that I am compressing to M2.
Maybe I should not have done that :)


> Unfortunately all the legacy support stuff got dramatically delayed due
> to a personal desaster of a team member. At this very moment I even
> can't promise that it will make it to 2.0 GA ;-(


I hope this is not too bad.
CDO team is very cool, and the project is very promising.


> Cheers
> /Eike

> ----
> http://thegordian.blogspot.com


>>
>> Thanks,
>> Guillaume.
>>
Re: [CDO] Legacy and Oracle. [message #428686 is a reply to message #428498] Thu, 26 March 2009 15:35 Go to previous messageGo to next message
Guillaume Brocard is currently offline Guillaume BrocardFriend
Messages: 25
Registered: July 2009
Junior Member
Hi Victor,

I decided to give the Oracle adapter a try but I am a bit overwhelmed by
the issues (I am certainly no db specialist).

First of all, the introspection made for the data source feeding is a bit
messy. That leads to having a strangly named parameter uRL, because the
method in OracleDataSource is named setURL (upper case). I would have
prefered a non-case sensitive behavior (even if that might lead to another
issue).
Anyway, this one is easily fixed, in the cdo-server.xml file directly.

Now, I have written an OracleAdapter (at least I have started to do so
:)). The RESERVED_WORDS I have made from Oracle documentation, fine. At
that point, I can already tell that this is not SQL92 compliant.

So I have specialized getTypeName() to replace BIGINT by INTEGER, and to
prevent VARCHARs from exceeding 4000 bytes (for Oracle does not support
greater values). Fine...

I'm somehow stuck with the BOOLEAN case. Definitely not supported by
Oracle.
I can tweak it for a VARCHAR or an INTEGER.
But, I can't find a clear path to all accesses. I mean, the adapter is
clearly invoked at table creation time, but that's it.
I would also need to provide with a customized
PreparedStatementJDBCDelegate but that one is 1) internal (can be worked
around), 2) not much written for extensibility purposes. I mean, I have to
rewrite the whole doInsertAttributes() to get somewhere near my needs (and
I'm not even sure of that).
What about reading the values ? Where is that located ?

Finally, when I'm connecting to an already filled up database, net4j
DBUtil.getMaximumNumber() tries to retrieve some number of some sort,
expecting a Long value in return. Unfortunately, Oracle answers to "SELECT
MAX(created) FROM cdo_repository" with a BigDecimal. So I'm getting a
DBException, ending my attempt to connect to the database.

As far as I can see in the code, accesses to the connection, and its
results, are scattered everywhere. Would it not be easier to have a unique
central point as far as the db connection is concerned ? What am I missing
?

Thanks in advance,
Guillaume.


Guillaume Brocard wrote:

> Hi,

> Victor, thanks for your answers.
> As soon as I try to connect to Oracle, I'll let you know with the issues.

> Eike, comments below.

> Cheers,
> Guillaume.

> Eike Stepper wrote:

>> Guys,

>> The EMF vetoable listener support bugzilla is indeed the central enabler
>> for CDO legacy model support because it provides means to intercept all
>> read and write access to arbitrary (here: legacy) model objects. This is
>> needed to acquire read and write locks which, in turn, trigger demand
>> loading and so on...


> I still don't quite see how models that have been generated out of this
> scope will benefit from this feature. I mean those models don't even have
> the preGet/Set vetoable abilities (you can even think about 2.3 or 2.4 EMF
> models), so I'm a bit confused about their use, and then about the
> "legacy" meaning. With Aspect-J I could think of a way to enable legacy
> (using some preGet/Set pointcuts), but that does not seem to be the case
> anymore (as of CDO 2.0 at least).


>> There is also a CDO bugzilla about legacy model support. I can't recall
>> the id but it's blocked by the mentioned EMF bug.

>> Cheers
>> /Eike

>> ----
>> http://thegordian.blogspot.com



>> Víctor Roldán Betancort schrieb:
>>> Guillaume,
>>>
>>> comments below
>>>
>>>>>> We have tried several stores, from memory to mysql, and finally
>>>>>> elected hsqldb. But we are strongly asked to use Oracle. My first
>>>>>> question then : is there anyone out there contributing an Oracle
>>>>>> dbAdapter ?
>>>>
>>>>> No there isn't, but it's fairly easy to implement one, I believe. I
>>>>> did postresql adapter myself, and did took me a couple of hours to
>>>>> do so. If you are willing to implement it, don't hesitate asking
>>>>> here! And, of course, contributions will be welcome :)
>>>>
>>>>
>>>> I am willing, as this is the recommanded db in my group, but I'm not
>>>> sure that this is this simple. For instance, Oracle names can't
>>>> exceed 30 characters. Worst, a constraint (e.g. foreign key) must
>>>> have a unique name, whatever the table. I know this has more to do
>>>> with mapping strategies. Thus I would have to implement both to get
>>>> it to work.
>>>> Anyway, I'll give it a try, but I can't tell you when exactly, for I
>>>> need to focus on the other functionnalities now (and I may be able to
>>>> kick Oracle out of the game later).
>>>
>>> Having an Oracle DBAdapter was always in the plans of the CDO project,
>>> but somehow left a bit aside, since there are still many more
>>> important issues to tackle.
>>>
>>> I suspect both those two issues you point out can be managed at
>>> DBAdapter level, so you *shouldn't* need to implement any mapping
>>> strategy. For instance, for the index contraint, you might override
>>> org.eclipse.net4j.spi.db.DBAdapter.createIndex(IDBIndex, Statement,
>>> int) to fulfill Oracle peculiarities.
>>>
>>> In case it is really necessary, I think we should analyze your
>>> requirements and see whether they fit in the current design, so we can
>>> reach to some compromise in our default implementation and avoiding
>>> implementing your own mapping strategy. CDO should stay generic enough
>>> to give support to any JDBC compatible RDBMS. OODBMS are a complete
>>> different story :P
>>>
>>>>>> Now we would also like to test the application using the core M2.
>>>>>> It comes with a new M2, that, once instantiated, references models
>>>>>> from our core M2. Of course, this new M2 ain't generated by us
>>>>>> (that would be far too simple). Up to my second question (a
>>>>>> multiple one, sorry ;)): how about legacy support in CDO ? Should
>>>>>> we wait for the official release (in June I assume), or can we test
>>>>>> this already (and how ?) ?
>>>>
>>>>> As of M6, legacy is not yet implemented. We are currently waiting
>>>>> for some new EMF 2.5.0 features to come in. Take a look at:
>>>>
>>>>> Provide vetoable notification for read and write access
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130
>>>>
>>>> I don't quite see how it would help implement legacy.
>>>> I mean surely newly generated models could take advantage of this
>>>> feature, but what about already existing ones ?
>>>
>>> Me neither xD But according to Eike, it does :P I believe this is just
>>> one of the necessary requirements, there are still issues to overcome...
>>> Eike can probably say more about this, but unfortunately (for us that
>>> are not there :P) he's now at EclipseCon.
>>>
>>> Maybe Ed knows a bit of Eike's plans?
>>>
>>> Cheers,
>>> ViK.
Re: [CDO] Legacy and Oracle. [message #428692 is a reply to message #428686] Thu, 26 March 2009 17:48 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Guillaume,

I must say I haven't gone that far in developing a DBAdapter for CDO :P
I don't think I have the enough knowledge to asses you in this topic.
Eike and Simon are on the Con, and Stefan (the DBStore guy) is on
vacation, I believe.

Some comments below


> I'm somehow stuck with the BOOLEAN case. Definitely not supported by Oracle.
> I can tweak it for a VARCHAR or an INTEGER.
> But, I can't find a clear path to all accesses. I mean, the adapter is clearly invoked at table creation time, but that's it.
> I would also need to provide with a customized PreparedStatementJDBCDelegate but that one is 1) internal (can be worked around), 2) not much written for extensibility purposes. I mean, I have to rewrite the whole doInsertAttributes() to get somewhere near my needs (and I'm not even sure of that).
> What about reading the values ? Where is that located ?

Have you tried StatementJDBCDelegateProvider? I guess you probably want
to take advantange of Oracle PreparedStatement, but just in case it
makes things work better for you in the meanwhile...

> As far as I can see in the code, accesses to the connection, and its
> results, are scattered everywhere. Would it not be easier to have a
> unique central point as far as the db connection is concerned ? What am
> I missing ?

I would say that anything that you can't customize in your DBAdapter and
plays an important role in the DBStore backend, is probably a limitation
we didn't foresee (too obvious?) :P This is closely related with the
interoperability between the different RDBMS vendors (yeah, JDBC and
SQL92... but we all know how things work in practice :P)

We appreciate the time you are investing on this, this would definitely
help us identify those points that require refactor and improved
extensibility. I guess this kind of problems pop up as we start working
with non-compliant propiertary solutions. In the worst case, you would
need to modify DBStore with specifics of the the Oracle RDBMS, but we
should try to avoid that. As I said before, we must identify those parts
of the code that need to be factored out from DBStore. I my opinion,
user should only contribute with one IDBAdapter implementation to get
full control over the specifics of the DDL and DML of the RDBMS.

Again, apologies for not being of much help. Hopefully the guys can jump
in soon.

Víctor.
Re: [CDO] Legacy and Oracle. [message #428720 is a reply to message #428692] Fri, 27 March 2009 15:36 Go to previous messageGo to next message
Guillaume Brocard is currently offline Guillaume BrocardFriend
Messages: 25
Registered: July 2009
Junior Member
Hi Victor,

thanks for your answers.

I have found some others incompatibilities with Oracle and cdo db
framework.
The batch statement returns -2 with Oracle, whereas, 1 is hard-code tested
in cdo (btw, why not refer to java.sql.Statement constants ?). So I am
providing a dedicated PreparedStatementJDBCDelegate.

As for get/set actions on modified types (because of Oracle not being
sql92 compliant), I'm pretty sure that requires a dedicated mapping
strategy with specific AttributeMapping :(.

As soon as the guys jump in, I can fill a bugzilla with all the required
modifications... let me know.

Guillaume.

Víctor Roldán Betancort wrote:

> Guillaume,

> I must say I haven't gone that far in developing a DBAdapter for CDO :P
> I don't think I have the enough knowledge to asses you in this topic.
> Eike and Simon are on the Con, and Stefan (the DBStore guy) is on
> vacation, I believe.

> Some comments below


>> I'm somehow stuck with the BOOLEAN case. Definitely not supported by Oracle.
>> I can tweak it for a VARCHAR or an INTEGER.
>> But, I can't find a clear path to all accesses. I mean, the adapter is
clearly invoked at table creation time, but that's it.
>> I would also need to provide with a customized
PreparedStatementJDBCDelegate but that one is 1) internal (can be worked
around), 2) not much written for extensibility purposes. I mean, I have to
rewrite the whole doInsertAttributes() to get somewhere near my needs (and I'm
not even sure of that).
>> What about reading the values ? Where is that located ?

> Have you tried StatementJDBCDelegateProvider? I guess you probably want
> to take advantange of Oracle PreparedStatement, but just in case it
> makes things work better for you in the meanwhile...

>> As far as I can see in the code, accesses to the connection, and its
>> results, are scattered everywhere. Would it not be easier to have a
>> unique central point as far as the db connection is concerned ? What am
>> I missing ?

> I would say that anything that you can't customize in your DBAdapter and
> plays an important role in the DBStore backend, is probably a limitation
> we didn't foresee (too obvious?) :P This is closely related with the
> interoperability between the different RDBMS vendors (yeah, JDBC and
> SQL92... but we all know how things work in practice :P)

> We appreciate the time you are investing on this, this would definitely
> help us identify those points that require refactor and improved
> extensibility. I guess this kind of problems pop up as we start working
> with non-compliant propiertary solutions. In the worst case, you would
> need to modify DBStore with specifics of the the Oracle RDBMS, but we
> should try to avoid that. As I said before, we must identify those parts
> of the code that need to be factored out from DBStore. I my opinion,
> user should only contribute with one IDBAdapter implementation to get
> full control over the specifics of the DDL and DML of the RDBMS.

> Again, apologies for not being of much help. Hopefully the guys can jump
> in soon.

> Víctor.
Re: [CDO] Legacy and Oracle. [message #428727 is a reply to message #428720] Fri, 27 March 2009 19:50 Go to previous messageGo to next message
Hasan Ceylan is currently offline Hasan CeylanFriend
Messages: 198
Registered: July 2009
Senior Member
Hi Victor & Guillaume

We have developped an oracle adapter for CDO. You must also be aware that
CDO expects Integers from the jdbc in most of the places. So we also made a
wrapper JDC driver that translates the BigDecimals returned by Oracle jdbc
to Integers.

If CDO or you guys interested we can share the code...

Regards,
Hasan Ceylan

Guillaume Brocard wrote:

> Hi Victor,
>
> thanks for your answers.
>
> I have found some others incompatibilities with Oracle and cdo db
> framework.
> The batch statement returns -2 with Oracle, whereas, 1 is hard-code tested
> in cdo (btw, why not refer to java.sql.Statement constants ?). So I am
> providing a dedicated PreparedStatementJDBCDelegate.
>
> As for get/set actions on modified types (because of Oracle not being
> sql92 compliant), I'm pretty sure that requires a dedicated mapping
> strategy with specific AttributeMapping :(.
>
> As soon as the guys jump in, I can fill a bugzilla with all the required
> modifications... let me know.
>
> Guillaume.
>
> Víctor Roldán Betancort wrote:
>
>> Guillaume,
>
>> I must say I haven't gone that far in developing a DBAdapter for CDO :P
>> I don't think I have the enough knowledge to asses you in this topic.
>> Eike and Simon are on the Con, and Stefan (the DBStore guy) is on
>> vacation, I believe.
>
>> Some comments below
>
>
>>> I'm somehow stuck with the BOOLEAN case. Definitely not supported by
>>> Oracle. I can tweak it for a VARCHAR or an INTEGER.
>>> But, I can't find a clear path to all accesses. I mean, the adapter is
> clearly invoked at table creation time, but that's it.
>>> I would also need to provide with a customized
> PreparedStatementJDBCDelegate but that one is 1) internal (can be worked
> around), 2) not much written for extensibility purposes. I mean, I have to
> rewrite the whole doInsertAttributes() to get somewhere near my needs (and
> I'm not even sure of that).
>>> What about reading the values ? Where is that located ?
>
>> Have you tried StatementJDBCDelegateProvider? I guess you probably want
>> to take advantange of Oracle PreparedStatement, but just in case it
>> makes things work better for you in the meanwhile...
>
>>> As far as I can see in the code, accesses to the connection, and its
>>> results, are scattered everywhere. Would it not be easier to have a
>>> unique central point as far as the db connection is concerned ? What am
>>> I missing ?
>
>> I would say that anything that you can't customize in your DBAdapter and
>> plays an important role in the DBStore backend, is probably a limitation
>> we didn't foresee (too obvious?) :P This is closely related with the
>> interoperability between the different RDBMS vendors (yeah, JDBC and
>> SQL92... but we all know how things work in practice :P)
>
>> We appreciate the time you are investing on this, this would definitely
>> help us identify those points that require refactor and improved
>> extensibility. I guess this kind of problems pop up as we start working
>> with non-compliant propiertary solutions. In the worst case, you would
>> need to modify DBStore with specifics of the the Oracle RDBMS, but we
>> should try to avoid that. As I said before, we must identify those parts
>> of the code that need to be factored out from DBStore. I my opinion,
>> user should only contribute with one IDBAdapter implementation to get
>> full control over the specifics of the DDL and DML of the RDBMS.
>
>> Again, apologies for not being of much help. Hopefully the guys can jump
>> in soon.
>
>> Víctor.
Re: [CDO] Legacy and Oracle. [message #428731 is a reply to message #428727] Fri, 27 March 2009 22:30 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Hasan Ceylan wrote:

> Hi Victor & Guillaume

> We have developped an oracle adapter for CDO. You must also be aware that
> CDO expects Integers from the jdbc in most of the places. So we also made a
> wrapper JDC driver that translates the BigDecimals returned by Oracle jdbc
> to Integers.

> If CDO or you guys interested we can share the code...

I think we will be more than happy to integrate that code. What do you
think Stefan?

> Regards,
> Hasan Ceylan

> Guillaume Brocard wrote:

>> Hi Victor,
>>
>> thanks for your answers.
>>
>> I have found some others incompatibilities with Oracle and cdo db
>> framework.
>> The batch statement returns -2 with Oracle, whereas, 1 is hard-code tested
>> in cdo (btw, why not refer to java.sql.Statement constants ?). So I am
>> providing a dedicated PreparedStatementJDBCDelegate.
>>
>> As for get/set actions on modified types (because of Oracle not being
>> sql92 compliant), I'm pretty sure that requires a dedicated mapping
>> strategy with specific AttributeMapping :(.
>>
>> As soon as the guys jump in, I can fill a bugzilla with all the required
>> modifications... let me know.
>>
>> Guillaume.
>>
>> Víctor Roldán Betancort wrote:
>>
>>> Guillaume,
>>
>>> I must say I haven't gone that far in developing a DBAdapter for CDO :P
>>> I don't think I have the enough knowledge to asses you in this topic.
>>> Eike and Simon are on the Con, and Stefan (the DBStore guy) is on
>>> vacation, I believe.
>>
>>> Some comments below
>>
>>
>>>> I'm somehow stuck with the BOOLEAN case. Definitely not supported by
>>>> Oracle. I can tweak it for a VARCHAR or an INTEGER.
>>>> But, I can't find a clear path to all accesses. I mean, the adapter is
>> clearly invoked at table creation time, but that's it.
>>>> I would also need to provide with a customized
>> PreparedStatementJDBCDelegate but that one is 1) internal (can be worked
>> around), 2) not much written for extensibility purposes. I mean, I have to
>> rewrite the whole doInsertAttributes() to get somewhere near my needs (and
>> I'm not even sure of that).
>>>> What about reading the values ? Where is that located ?
>>
>>> Have you tried StatementJDBCDelegateProvider? I guess you probably want
>>> to take advantange of Oracle PreparedStatement, but just in case it
>>> makes things work better for you in the meanwhile...
>>
>>>> As far as I can see in the code, accesses to the connection, and its
>>>> results, are scattered everywhere. Would it not be easier to have a
>>>> unique central point as far as the db connection is concerned ? What am
>>>> I missing ?
>>
>>> I would say that anything that you can't customize in your DBAdapter and
>>> plays an important role in the DBStore backend, is probably a limitation
>>> we didn't foresee (too obvious?) :P This is closely related with the
>>> interoperability between the different RDBMS vendors (yeah, JDBC and
>>> SQL92... but we all know how things work in practice :P)
>>
>>> We appreciate the time you are investing on this, this would definitely
>>> help us identify those points that require refactor and improved
>>> extensibility. I guess this kind of problems pop up as we start working
>>> with non-compliant propiertary solutions. In the worst case, you would
>>> need to modify DBStore with specifics of the the Oracle RDBMS, but we
>>> should try to avoid that. As I said before, we must identify those parts
>>> of the code that need to be factored out from DBStore. I my opinion,
>>> user should only contribute with one IDBAdapter implementation to get
>>> full control over the specifics of the DDL and DML of the RDBMS.
>>
>>> Again, apologies for not being of much help. Hopefully the guys can jump
>>> in soon.
>>
>>> Víctor.
Re: [CDO] Legacy and Oracle. [message #428740 is a reply to message #428731] Sat, 28 March 2009 12:07 Go to previous messageGo to next message
Guillaume Brocard is currently offline Guillaume BrocardFriend
Messages: 25
Registered: July 2009
Junior Member
Hi Hasan,

I was almost going crazy with this BigDecimal attitude !

As far as I understand, every number is converted to BigDecimal by the
Oracle jdbc implementation. How did you manage to make a difference (let
say between an Integer and a Long) ?

Anyway, should you contribute the code, I would be more than happy :)

Thanks,
Guillaume.

Simon Mc Duff wrote:

> Hasan Ceylan wrote:

>> Hi Victor & Guillaume

>> We have developped an oracle adapter for CDO. You must also be aware that
>> CDO expects Integers from the jdbc in most of the places. So we also made a
>> wrapper JDC driver that translates the BigDecimals returned by Oracle jdbc
>> to Integers.

>> If CDO or you guys interested we can share the code...

> I think we will be more than happy to integrate that code. What do you
> think Stefan?

>> Regards,
>> Hasan Ceylan

>> Guillaume Brocard wrote:

>>> Hi Victor,
>>>
>>> thanks for your answers.
>>>
>>> I have found some others incompatibilities with Oracle and cdo db
>>> framework.
>>> The batch statement returns -2 with Oracle, whereas, 1 is hard-code tested
>>> in cdo (btw, why not refer to java.sql.Statement constants ?). So I am
>>> providing a dedicated PreparedStatementJDBCDelegate.
>>>
>>> As for get/set actions on modified types (because of Oracle not being
>>> sql92 compliant), I'm pretty sure that requires a dedicated mapping
>>> strategy with specific AttributeMapping :(.
>>>
>>> As soon as the guys jump in, I can fill a bugzilla with all the required
>>> modifications... let me know.
>>>
>>> Guillaume.
>>>
>>> Víctor Roldán Betancort wrote:
>>>
>>>> Guillaume,
>>>
>>>> I must say I haven't gone that far in developing a DBAdapter for CDO :P
>>>> I don't think I have the enough knowledge to asses you in this topic.
>>>> Eike and Simon are on the Con, and Stefan (the DBStore guy) is on
>>>> vacation, I believe.
>>>
>>>> Some comments below
>>>
>>>
>>>>> I'm somehow stuck with the BOOLEAN case. Definitely not supported by
>>>>> Oracle. I can tweak it for a VARCHAR or an INTEGER.
>>>>> But, I can't find a clear path to all accesses. I mean, the adapter is
>>> clearly invoked at table creation time, but that's it.
>>>>> I would also need to provide with a customized
>>> PreparedStatementJDBCDelegate but that one is 1) internal (can be worked
>>> around), 2) not much written for extensibility purposes. I mean, I have to
>>> rewrite the whole doInsertAttributes() to get somewhere near my needs (and
>>> I'm not even sure of that).
>>>>> What about reading the values ? Where is that located ?
>>>
>>>> Have you tried StatementJDBCDelegateProvider? I guess you probably want
>>>> to take advantange of Oracle PreparedStatement, but just in case it
>>>> makes things work better for you in the meanwhile...
>>>
>>>>> As far as I can see in the code, accesses to the connection, and its
>>>>> results, are scattered everywhere. Would it not be easier to have a
>>>>> unique central point as far as the db connection is concerned ? What am
>>>>> I missing ?
>>>
>>>> I would say that anything that you can't customize in your DBAdapter and
>>>> plays an important role in the DBStore backend, is probably a limitation
>>>> we didn't foresee (too obvious?) :P This is closely related with the
>>>> interoperability between the different RDBMS vendors (yeah, JDBC and
>>>> SQL92... but we all know how things work in practice :P)
>>>
>>>> We appreciate the time you are investing on this, this would definitely
>>>> help us identify those points that require refactor and improved
>>>> extensibility. I guess this kind of problems pop up as we start working
>>>> with non-compliant propiertary solutions. In the worst case, you would
>>>> need to modify DBStore with specifics of the the Oracle RDBMS, but we
>>>> should try to avoid that. As I said before, we must identify those parts
>>>> of the code that need to be factored out from DBStore. I my opinion,
>>>> user should only contribute with one IDBAdapter implementation to get
>>>> full control over the specifics of the DDL and DML of the RDBMS.
>>>
>>>> Again, apologies for not being of much help. Hopefully the guys can jump
>>>> in soon.
>>>
>>>> Víctor.
Re: [CDO] Legacy and Oracle. [message #428753 is a reply to message #428498] Sun, 29 March 2009 10:27 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Guillaume,

When we talk about "legacy models" in CDO we mean models whose classes
do not implement InternalCDOObject.

The usage of AspectJ or similar byte code engineering technologies can
address the problem and we used it in a former version. But it turned
out to be rather fragile because of EMF's huge collection library which
needs consideration as well.

Cheers
/Eike

----
http://thegordian.blogspot.com



Guillaume Brocard schrieb:
> Hi,
>
> Victor, thanks for your answers.
> As soon as I try to connect to Oracle, I'll let you know with the issues.
>
> Eike, comments below.
>
> Cheers,
> Guillaume.
>
> Eike Stepper wrote:
>
>> Guys,
>
>> The EMF vetoable listener support bugzilla is indeed the central
>> enabler for CDO legacy model support because it provides means to
>> intercept all read and write access to arbitrary (here: legacy) model
>> objects. This is needed to acquire read and write locks which, in
>> turn, trigger demand loading and so on...
>
>
> I still don't quite see how models that have been generated out of
> this scope will benefit from this feature. I mean those models don't
> even have the preGet/Set vetoable abilities (you can even think about
> 2.3 or 2.4 EMF models), so I'm a bit confused about their use, and
> then about the "legacy" meaning. With Aspect-J I could think of a way
> to enable legacy (using some preGet/Set pointcuts), but that does not
> seem to be the case anymore (as of CDO 2.0 at least).
>
>
>> There is also a CDO bugzilla about legacy model support. I can't
>> recall the id but it's blocked by the mentioned EMF bug.
>
>> Cheers
>> /Eike
>
>> ----
>> http://thegordian.blogspot.com
>
>
>
>> Víctor Roldán Betancort schrieb:
>>> Guillaume,
>>>
>>> comments below
>>>
>>>>>> We have tried several stores, from memory to mysql, and finally
>>>>>> elected hsqldb. But we are strongly asked to use Oracle. My first
>>>>>> question then : is there anyone out there contributing an Oracle
>>>>>> dbAdapter ?
>>>>
>>>>> No there isn't, but it's fairly easy to implement one, I believe.
>>>>> I did postresql adapter myself, and did took me a couple of hours
>>>>> to do so. If you are willing to implement it, don't hesitate
>>>>> asking here! And, of course, contributions will be welcome :)
>>>>
>>>>
>>>> I am willing, as this is the recommanded db in my group, but I'm
>>>> not sure that this is this simple. For instance, Oracle names can't
>>>> exceed 30 characters. Worst, a constraint (e.g. foreign key) must
>>>> have a unique name, whatever the table. I know this has more to do
>>>> with mapping strategies. Thus I would have to implement both to get
>>>> it to work.
>>>> Anyway, I'll give it a try, but I can't tell you when exactly, for
>>>> I need to focus on the other functionnalities now (and I may be
>>>> able to kick Oracle out of the game later).
>>>
>>> Having an Oracle DBAdapter was always in the plans of the CDO
>>> project, but somehow left a bit aside, since there are still many
>>> more important issues to tackle.
>>>
>>> I suspect both those two issues you point out can be managed at
>>> DBAdapter level, so you *shouldn't* need to implement any mapping
>>> strategy. For instance, for the index contraint, you might override
>>> org.eclipse.net4j.spi.db.DBAdapter.createIndex(IDBIndex, Statement,
>>> int) to fulfill Oracle peculiarities.
>>>
>>> In case it is really necessary, I think we should analyze your
>>> requirements and see whether they fit in the current design, so we
>>> can reach to some compromise in our default implementation and
>>> avoiding implementing your own mapping strategy. CDO should stay
>>> generic enough to give support to any JDBC compatible RDBMS. OODBMS
>>> are a complete different story :P
>>>
>>>>>> Now we would also like to test the application using the core M2.
>>>>>> It comes with a new M2, that, once instantiated, references
>>>>>> models from our core M2. Of course, this new M2 ain't generated
>>>>>> by us (that would be far too simple). Up to my second question (a
>>>>>> multiple one, sorry ;)): how about legacy support in CDO ? Should
>>>>>> we wait for the official release (in June I assume), or can we
>>>>>> test this already (and how ?) ?
>>>>
>>>>> As of M6, legacy is not yet implemented. We are currently waiting
>>>>> for some new EMF 2.5.0 features to come in. Take a look at:
>>>>
>>>>> Provide vetoable notification for read and write access
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130
>>>>
>>>> I don't quite see how it would help implement legacy.
>>>> I mean surely newly generated models could take advantage of this
>>>> feature, but what about already existing ones ?
>>>
>>> Me neither xD But according to Eike, it does :P I believe this is
>>> just one of the necessary requirements, there are still issues to
>>> overcome...
>>> Eike can probably say more about this, but unfortunately (for us
>>> that are not there :P) he's now at EclipseCon.
>>>
>>> Maybe Ed knows a bit of Eike's plans?
>>>
>>> Cheers,
>>> ViK.
>
>


Re: [CDO] Legacy and Oracle. [message #428754 is a reply to message #428740] Sun, 29 March 2009 10:30 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Guys,

Yes, we'd be happy to support Oracle and we appreciate any contribution
in this area. If changes in the framework are necessary for smoother
integration we certainly want to apply them.

Cheers
/Eike

----
http://thegordian.blogspot.com



Guillaume Brocard schrieb:
> Hi Hasan,
>
> I was almost going crazy with this BigDecimal attitude !
>
> As far as I understand, every number is converted to BigDecimal by the
> Oracle jdbc implementation. How did you manage to make a difference
> (let say between an Integer and a Long) ?
>
> Anyway, should you contribute the code, I would be more than happy :)
>
> Thanks,
> Guillaume.
>
> Simon Mc Duff wrote:
>
>> Hasan Ceylan wrote:
>
>>> Hi Victor & Guillaume
>
>>> We have developped an oracle adapter for CDO. You must also be aware
>>> that CDO expects Integers from the jdbc in most of the places. So we
>>> also made a wrapper JDC driver that translates the BigDecimals
>>> returned by Oracle jdbc to Integers.
>
>>> If CDO or you guys interested we can share the code...
>
>> I think we will be more than happy to integrate that code. What do
>> you think Stefan?
>
>>> Regards,
>>> Hasan Ceylan
>
>>> Guillaume Brocard wrote:
>
>>>> Hi Victor,
>>>>
>>>> thanks for your answers.
>>>>
>>>> I have found some others incompatibilities with Oracle and cdo db
>>>> framework.
>>>> The batch statement returns -2 with Oracle, whereas, 1 is hard-code
>>>> tested
>>>> in cdo (btw, why not refer to java.sql.Statement constants ?). So I am
>>>> providing a dedicated PreparedStatementJDBCDelegate.
>>>>
>>>> As for get/set actions on modified types (because of Oracle not being
>>>> sql92 compliant), I'm pretty sure that requires a dedicated mapping
>>>> strategy with specific AttributeMapping :(.
>>>>
>>>> As soon as the guys jump in, I can fill a bugzilla with all the
>>>> required
>>>> modifications... let me know.
>>>>
>>>> Guillaume.
>>>>
>>>> Víctor Roldán Betancort wrote:
>>>>
>>>>> Guillaume,
>>>>
>>>>> I must say I haven't gone that far in developing a DBAdapter for
>>>>> CDO :P
>>>>> I don't think I have the enough knowledge to asses you in this topic.
>>>>> Eike and Simon are on the Con, and Stefan (the DBStore guy) is on
>>>>> vacation, I believe.
>>>>
>>>>> Some comments below
>>>>
>>>>
>>>>>> I'm somehow stuck with the BOOLEAN case. Definitely not supported by
>>>>>> Oracle. I can tweak it for a VARCHAR or an INTEGER.
>>>>>> But, I can't find a clear path to all accesses. I mean, the
>>>>>> adapter is
>>>> clearly invoked at table creation time, but that's it.
>>>>>> I would also need to provide with a customized
>>>> PreparedStatementJDBCDelegate but that one is 1) internal (can be
>>>> worked
>>>> around), 2) not much written for extensibility purposes. I mean, I
>>>> have to
>>>> rewrite the whole doInsertAttributes() to get somewhere near my
>>>> needs (and
>>>> I'm not even sure of that).
>>>>>> What about reading the values ? Where is that located ?
>>>>
>>>>> Have you tried StatementJDBCDelegateProvider? I guess you probably
>>>>> want
>>>>> to take advantange of Oracle PreparedStatement, but just in case it
>>>>> makes things work better for you in the meanwhile...
>>>>
>>>>>> As far as I can see in the code, accesses to the connection, and its
>>>>>> results, are scattered everywhere. Would it not be easier to have a
>>>>>> unique central point as far as the db connection is concerned ?
>>>>>> What am
>>>>>> I missing ?
>>>>
>>>>> I would say that anything that you can't customize in your
>>>>> DBAdapter and
>>>>> plays an important role in the DBStore backend, is probably a
>>>>> limitation
>>>>> we didn't foresee (too obvious?) :P This is closely related with the
>>>>> interoperability between the different RDBMS vendors (yeah, JDBC and
>>>>> SQL92... but we all know how things work in practice :P)
>>>>
>>>>> We appreciate the time you are investing on this, this would
>>>>> definitely
>>>>> help us identify those points that require refactor and improved
>>>>> extensibility. I guess this kind of problems pop up as we start
>>>>> working
>>>>> with non-compliant propiertary solutions. In the worst case, you
>>>>> would
>>>>> need to modify DBStore with specifics of the the Oracle RDBMS, but we
>>>>> should try to avoid that. As I said before, we must identify those
>>>>> parts
>>>>> of the code that need to be factored out from DBStore. I my opinion,
>>>>> user should only contribute with one IDBAdapter implementation to get
>>>>> full control over the specifics of the DDL and DML of the RDBMS.
>>>>
>>>>> Again, apologies for not being of much help. Hopefully the guys
>>>>> can jump
>>>>> in soon.
>>>>
>>>>> Víctor.
>
>


Re: [CDO] Legacy and Oracle. [message #428768 is a reply to message #428754] Mon, 30 March 2009 08:00 Go to previous messageGo to next message
Guillaume Brocard is currently offline Guillaume BrocardFriend
Messages: 25
Registered: July 2009
Junior Member
Hi,

I can test Hasan's contribution very quickly if you want (on my models),
if any. If none, let me know, so that I may continue my work on this
subject.

Btw, which cdo version are you using Hasan ?

Cheers,
Guillaume.

Eike Stepper wrote:

> Guys,

> Yes, we'd be happy to support Oracle and we appreciate any contribution
> in this area. If changes in the framework are necessary for smoother
> integration we certainly want to apply them.

> Cheers
> /Eike

> ----
> http://thegordian.blogspot.com



> Guillaume Brocard schrieb:
>> Hi Hasan,
>>
>> I was almost going crazy with this BigDecimal attitude !
>>
>> As far as I understand, every number is converted to BigDecimal by the
>> Oracle jdbc implementation. How did you manage to make a difference
>> (let say between an Integer and a Long) ?
>>
>> Anyway, should you contribute the code, I would be more than happy :)
>>
>> Thanks,
>> Guillaume.
>>
>> Simon Mc Duff wrote:
>>
>>> Hasan Ceylan wrote:
>>
>>>> Hi Victor & Guillaume
>>
>>>> We have developped an oracle adapter for CDO. You must also be aware
>>>> that CDO expects Integers from the jdbc in most of the places. So we
>>>> also made a wrapper JDC driver that translates the BigDecimals
>>>> returned by Oracle jdbc to Integers.
>>
>>>> If CDO or you guys interested we can share the code...
>>
>>> I think we will be more than happy to integrate that code. What do
>>> you think Stefan?
>>
>>>> Regards,
>>>> Hasan Ceylan
>>
>>>> Guillaume Brocard wrote:
>>
>>>>> Hi Victor,
>>>>>
>>>>> thanks for your answers.
>>>>>
>>>>> I have found some others incompatibilities with Oracle and cdo db
>>>>> framework.
>>>>> The batch statement returns -2 with Oracle, whereas, 1 is hard-code
>>>>> tested
>>>>> in cdo (btw, why not refer to java.sql.Statement constants ?). So I am
>>>>> providing a dedicated PreparedStatementJDBCDelegate.
>>>>>
>>>>> As for get/set actions on modified types (because of Oracle not being
>>>>> sql92 compliant), I'm pretty sure that requires a dedicated mapping
>>>>> strategy with specific AttributeMapping :(.
>>>>>
>>>>> As soon as the guys jump in, I can fill a bugzilla with all the
>>>>> required
>>>>> modifications... let me know.
>>>>>
>>>>> Guillaume.
>>>>>
>>>>> Víctor Roldán Betancort wrote:
>>>>>
>>>>>> Guillaume,
>>>>>
>>>>>> I must say I haven't gone that far in developing a DBAdapter for
>>>>>> CDO :P
>>>>>> I don't think I have the enough knowledge to asses you in this topic.
>>>>>> Eike and Simon are on the Con, and Stefan (the DBStore guy) is on
>>>>>> vacation, I believe.
>>>>>
>>>>>> Some comments below
>>>>>
>>>>>
>>>>>>> I'm somehow stuck with the BOOLEAN case. Definitely not supported by
>>>>>>> Oracle. I can tweak it for a VARCHAR or an INTEGER.
>>>>>>> But, I can't find a clear path to all accesses. I mean, the
>>>>>>> adapter is
>>>>> clearly invoked at table creation time, but that's it.
>>>>>>> I would also need to provide with a customized
>>>>> PreparedStatementJDBCDelegate but that one is 1) internal (can be
>>>>> worked
>>>>> around), 2) not much written for extensibility purposes. I mean, I
>>>>> have to
>>>>> rewrite the whole doInsertAttributes() to get somewhere near my
>>>>> needs (and
>>>>> I'm not even sure of that).
>>>>>>> What about reading the values ? Where is that located ?
>>>>>
>>>>>> Have you tried StatementJDBCDelegateProvider? I guess you probably
>>>>>> want
>>>>>> to take advantange of Oracle PreparedStatement, but just in case it
>>>>>> makes things work better for you in the meanwhile...
>>>>>
>>>>>>> As far as I can see in the code, accesses to the connection, and its
>>>>>>> results, are scattered everywhere. Would it not be easier to have a
>>>>>>> unique central point as far as the db connection is concerned ?
>>>>>>> What am
>>>>>>> I missing ?
>>>>>
>>>>>> I would say that anything that you can't customize in your
>>>>>> DBAdapter and
>>>>>> plays an important role in the DBStore backend, is probably a
>>>>>> limitation
>>>>>> we didn't foresee (too obvious?) :P This is closely related with the
>>>>>> interoperability between the different RDBMS vendors (yeah, JDBC and
>>>>>> SQL92... but we all know how things work in practice :P)
>>>>>
>>>>>> We appreciate the time you are investing on this, this would
>>>>>> definitely
>>>>>> help us identify those points that require refactor and improved
>>>>>> extensibility. I guess this kind of problems pop up as we start
>>>>>> working
>>>>>> with non-compliant propiertary solutions. In the worst case, you
>>>>>> would
>>>>>> need to modify DBStore with specifics of the the Oracle RDBMS, but we
>>>>>> should try to avoid that. As I said before, we must identify those
>>>>>> parts
>>>>>> of the code that need to be factored out from DBStore. I my opinion,
>>>>>> user should only contribute with one IDBAdapter implementation to get
>>>>>> full control over the specifics of the DDL and DML of the RDBMS.
>>>>>
>>>>>> Again, apologies for not being of much help. Hopefully the guys
>>>>>> can jump
>>>>>> in soon.
>>>>>
>>>>>> Víctor.
>>
>>
Re: [CDO] Legacy and Oracle. [message #428772 is a reply to message #428768] Mon, 30 March 2009 10:14 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Guys,

I've raised a bugzilla and added you in CC. Hopefully Hasan would be
able to share the code so we can take a look :)

[DB] Provide Oracle RDBMS integration
https://bugs.eclipse.org/bugs/show_bug.cgi?id=270428

Cheers,
ViK.

Guillaume Brocard escribió:
> Hi,
>
> I can test Hasan's contribution very quickly if you want (on my models),
> if any. If none, let me know, so that I may continue my work on this
> subject.
>
> Btw, which cdo version are you using Hasan ?
>
> Cheers,
> Guillaume.
>
> Eike Stepper wrote:
>
>> Guys,
>
>> Yes, we'd be happy to support Oracle and we appreciate any
>> contribution in this area. If changes in the framework are necessary
>> for smoother integration we certainly want to apply them.
>
>> Cheers
>> /Eike
>
>> ----
>> http://thegordian.blogspot.com
>
>
>
>> Guillaume Brocard schrieb:
>>> Hi Hasan,
>>>
>>> I was almost going crazy with this BigDecimal attitude !
>>>
>>> As far as I understand, every number is converted to BigDecimal by
>>> the Oracle jdbc implementation. How did you manage to make a
>>> difference (let say between an Integer and a Long) ?
>>>
>>> Anyway, should you contribute the code, I would be more than happy :)
>>>
>>> Thanks,
>>> Guillaume.
>>>
>>> Simon Mc Duff wrote:
>>>
>>>> Hasan Ceylan wrote:
>>>
>>>>> Hi Victor & Guillaume
>>>
>>>>> We have developped an oracle adapter for CDO. You must also be
>>>>> aware that CDO expects Integers from the jdbc in most of the
>>>>> places. So we also made a wrapper JDC driver that translates the
>>>>> BigDecimals returned by Oracle jdbc to Integers.
>>>
>>>>> If CDO or you guys interested we can share the code...
>>>
>>>> I think we will be more than happy to integrate that code. What do
>>>> you think Stefan?
>>>
>>>>> Regards,
>>>>> Hasan Ceylan
>>>
>>>>> Guillaume Brocard wrote:
>>>
>>>>>> Hi Victor,
>>>>>>
>>>>>> thanks for your answers.
>>>>>>
>>>>>> I have found some others incompatibilities with Oracle and cdo db
>>>>>> framework.
>>>>>> The batch statement returns -2 with Oracle, whereas, 1 is
>>>>>> hard-code tested
>>>>>> in cdo (btw, why not refer to java.sql.Statement constants ?). So
>>>>>> I am
>>>>>> providing a dedicated PreparedStatementJDBCDelegate.
>>>>>>
>>>>>> As for get/set actions on modified types (because of Oracle not being
>>>>>> sql92 compliant), I'm pretty sure that requires a dedicated mapping
>>>>>> strategy with specific AttributeMapping :(.
>>>>>>
>>>>>> As soon as the guys jump in, I can fill a bugzilla with all the
>>>>>> required
>>>>>> modifications... let me know.
>>>>>>
>>>>>> Guillaume.
>>>>>>
>>>>>> Víctor Roldán Betancort wrote:
>>>>>>
>>>>>>> Guillaume,
>>>>>>
>>>>>>> I must say I haven't gone that far in developing a DBAdapter for
>>>>>>> CDO :P
>>>>>>> I don't think I have the enough knowledge to asses you in this
>>>>>>> topic.
>>>>>>> Eike and Simon are on the Con, and Stefan (the DBStore guy) is on
>>>>>>> vacation, I believe.
>>>>>>
>>>>>>> Some comments below
>>>>>>
>>>>>>
>>>>>>>> I'm somehow stuck with the BOOLEAN case. Definitely not
>>>>>>>> supported by
>>>>>>>> Oracle. I can tweak it for a VARCHAR or an INTEGER.
>>>>>>>> But, I can't find a clear path to all accesses. I mean, the
>>>>>>>> adapter is
>>>>>> clearly invoked at table creation time, but that's it.
>>>>>>>> I would also need to provide with a customized
>>>>>> PreparedStatementJDBCDelegate but that one is 1) internal (can be
>>>>>> worked
>>>>>> around), 2) not much written for extensibility purposes. I mean, I
>>>>>> have to
>>>>>> rewrite the whole doInsertAttributes() to get somewhere near my
>>>>>> needs (and
>>>>>> I'm not even sure of that).
>>>>>>>> What about reading the values ? Where is that located ?
>>>>>>
>>>>>>> Have you tried StatementJDBCDelegateProvider? I guess you
>>>>>>> probably want
>>>>>>> to take advantange of Oracle PreparedStatement, but just in case it
>>>>>>> makes things work better for you in the meanwhile...
>>>>>>
>>>>>>>> As far as I can see in the code, accesses to the connection, and
>>>>>>>> its
>>>>>>>> results, are scattered everywhere. Would it not be easier to have a
>>>>>>>> unique central point as far as the db connection is concerned ?
>>>>>>>> What am
>>>>>>>> I missing ?
>>>>>>
>>>>>>> I would say that anything that you can't customize in your
>>>>>>> DBAdapter and
>>>>>>> plays an important role in the DBStore backend, is probably a
>>>>>>> limitation
>>>>>>> we didn't foresee (too obvious?) :P This is closely related with the
>>>>>>> interoperability between the different RDBMS vendors (yeah, JDBC and
>>>>>>> SQL92... but we all know how things work in practice :P)
>>>>>>
>>>>>>> We appreciate the time you are investing on this, this would
>>>>>>> definitely
>>>>>>> help us identify those points that require refactor and improved
>>>>>>> extensibility. I guess this kind of problems pop up as we start
>>>>>>> working
>>>>>>> with non-compliant propiertary solutions. In the worst case, you
>>>>>>> would
>>>>>>> need to modify DBStore with specifics of the the Oracle RDBMS,
>>>>>>> but we
>>>>>>> should try to avoid that. As I said before, we must identify
>>>>>>> those parts
>>>>>>> of the code that need to be factored out from DBStore. I my opinion,
>>>>>>> user should only contribute with one IDBAdapter implementation to
>>>>>>> get
>>>>>>> full control over the specifics of the DDL and DML of the RDBMS.
>>>>>>
>>>>>>> Again, apologies for not being of much help. Hopefully the guys
>>>>>>> can jump
>>>>>>> in soon.
>>>>>>
>>>>>>> Víctor.
>>>
>>>
>
>
Re: [CDO] Legacy and Oracle. [message #428798 is a reply to message #428772] Mon, 30 March 2009 18:46 Go to previous message
Hasan Ceylan is currently offline Hasan CeylanFriend
Messages: 198
Registered: July 2009
Senior Member
Sorry Guys,

I was stacked up enormously lately.

I will share the code ASAP.

Hasan

Víctor Roldán Betancort wrote:

> Guys,
>
> I've raised a bugzilla and added you in CC. Hopefully Hasan would be
> able to share the code so we can take a look :)
>
> [DB] Provide Oracle RDBMS integration
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270428
>
> Cheers,
> ViK.
>
> Guillaume Brocard escribió:
>> Hi,
>>
>> I can test Hasan's contribution very quickly if you want (on my models),
>> if any. If none, let me know, so that I may continue my work on this
>> subject.
>>
>> Btw, which cdo version are you using Hasan ?
>>
>> Cheers,
>> Guillaume.
>>
>> Eike Stepper wrote:
>>
>>> Guys,
>>
>>> Yes, we'd be happy to support Oracle and we appreciate any
>>> contribution in this area. If changes in the framework are necessary
>>> for smoother integration we certainly want to apply them.
>>
>>> Cheers
>>> /Eike
>>
>>> ----
>>> http://thegordian.blogspot.com
>>
>>
>>
>>> Guillaume Brocard schrieb:
>>>> Hi Hasan,
>>>>
>>>> I was almost going crazy with this BigDecimal attitude !
>>>>
>>>> As far as I understand, every number is converted to BigDecimal by
>>>> the Oracle jdbc implementation. How did you manage to make a
>>>> difference (let say between an Integer and a Long) ?
>>>>
>>>> Anyway, should you contribute the code, I would be more than happy :)
>>>>
>>>> Thanks,
>>>> Guillaume.
>>>>
>>>> Simon Mc Duff wrote:
>>>>
>>>>> Hasan Ceylan wrote:
>>>>
>>>>>> Hi Victor & Guillaume
>>>>
>>>>>> We have developped an oracle adapter for CDO. You must also be
>>>>>> aware that CDO expects Integers from the jdbc in most of the
>>>>>> places. So we also made a wrapper JDC driver that translates the
>>>>>> BigDecimals returned by Oracle jdbc to Integers.
>>>>
>>>>>> If CDO or you guys interested we can share the code...
>>>>
>>>>> I think we will be more than happy to integrate that code. What do
>>>>> you think Stefan?
>>>>
>>>>>> Regards,
>>>>>> Hasan Ceylan
>>>>
>>>>>> Guillaume Brocard wrote:
>>>>
>>>>>>> Hi Victor,
>>>>>>>
>>>>>>> thanks for your answers.
>>>>>>>
>>>>>>> I have found some others incompatibilities with Oracle and cdo db
>>>>>>> framework.
>>>>>>> The batch statement returns -2 with Oracle, whereas, 1 is
>>>>>>> hard-code tested
>>>>>>> in cdo (btw, why not refer to java.sql.Statement constants ?). So
>>>>>>> I am
>>>>>>> providing a dedicated PreparedStatementJDBCDelegate.
>>>>>>>
>>>>>>> As for get/set actions on modified types (because of Oracle not
>>>>>>> being sql92 compliant), I'm pretty sure that requires a dedicated
>>>>>>> mapping strategy with specific AttributeMapping :(.
>>>>>>>
>>>>>>> As soon as the guys jump in, I can fill a bugzilla with all the
>>>>>>> required
>>>>>>> modifications... let me know.
>>>>>>>
>>>>>>> Guillaume.
>>>>>>>
>>>>>>> Víctor Roldán Betancort wrote:
>>>>>>>
>>>>>>>> Guillaume,
>>>>>>>
>>>>>>>> I must say I haven't gone that far in developing a DBAdapter for
>>>>>>>> CDO :P
>>>>>>>> I don't think I have the enough knowledge to asses you in this
>>>>>>>> topic.
>>>>>>>> Eike and Simon are on the Con, and Stefan (the DBStore guy) is on
>>>>>>>> vacation, I believe.
>>>>>>>
>>>>>>>> Some comments below
>>>>>>>
>>>>>>>
>>>>>>>>> I'm somehow stuck with the BOOLEAN case. Definitely not
>>>>>>>>> supported by
>>>>>>>>> Oracle. I can tweak it for a VARCHAR or an INTEGER.
>>>>>>>>> But, I can't find a clear path to all accesses. I mean, the
>>>>>>>>> adapter is
>>>>>>> clearly invoked at table creation time, but that's it.
>>>>>>>>> I would also need to provide with a customized
>>>>>>> PreparedStatementJDBCDelegate but that one is 1) internal (can be
>>>>>>> worked
>>>>>>> around), 2) not much written for extensibility purposes. I mean, I
>>>>>>> have to
>>>>>>> rewrite the whole doInsertAttributes() to get somewhere near my
>>>>>>> needs (and
>>>>>>> I'm not even sure of that).
>>>>>>>>> What about reading the values ? Where is that located ?
>>>>>>>
>>>>>>>> Have you tried StatementJDBCDelegateProvider? I guess you
>>>>>>>> probably want
>>>>>>>> to take advantange of Oracle PreparedStatement, but just in case it
>>>>>>>> makes things work better for you in the meanwhile...
>>>>>>>
>>>>>>>>> As far as I can see in the code, accesses to the connection, and
>>>>>>>>> its
>>>>>>>>> results, are scattered everywhere. Would it not be easier to have
>>>>>>>>> a unique central point as far as the db connection is concerned ?
>>>>>>>>> What am
>>>>>>>>> I missing ?
>>>>>>>
>>>>>>>> I would say that anything that you can't customize in your
>>>>>>>> DBAdapter and
>>>>>>>> plays an important role in the DBStore backend, is probably a
>>>>>>>> limitation
>>>>>>>> we didn't foresee (too obvious?) :P This is closely related with
>>>>>>>> the interoperability between the different RDBMS vendors (yeah,
>>>>>>>> JDBC and SQL92... but we all know how things work in practice :P)
>>>>>>>
>>>>>>>> We appreciate the time you are investing on this, this would
>>>>>>>> definitely
>>>>>>>> help us identify those points that require refactor and improved
>>>>>>>> extensibility. I guess this kind of problems pop up as we start
>>>>>>>> working
>>>>>>>> with non-compliant propiertary solutions. In the worst case, you
>>>>>>>> would
>>>>>>>> need to modify DBStore with specifics of the the Oracle RDBMS,
>>>>>>>> but we
>>>>>>>> should try to avoid that. As I said before, we must identify
>>>>>>>> those parts
>>>>>>>> of the code that need to be factored out from DBStore. I my
>>>>>>>> opinion, user should only contribute with one IDBAdapter
>>>>>>>> implementation to get
>>>>>>>> full control over the specifics of the DDL and DML of the RDBMS.
>>>>>>>
>>>>>>>> Again, apologies for not being of much help. Hopefully the guys
>>>>>>>> can jump
>>>>>>>> in soon.
>>>>>>>
>>>>>>>> Víctor.
>>>>
>>>>
>>
>>
Previous Topic:EPackage Implementation to EPAckage Class
Next Topic:Nested Notification Question
Goto Forum:
  


Current Time: Fri Mar 29 14:28:46 GMT 2024

Powered by FUDForum. Page generated in 0.03693 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top