|
| Re: [CDO] Oracle: Writing null to boolean value probably should use Types.BIT instead if Types.BOOLE [message #1188357 is a reply to message #1188342] |
Fri, 15 November 2013 15:41   |
|
Hi Leonid,
I'm sorry to say that FeatureMaps don't work with CDO. As you've seen we've made initial attempts to support them quite
some time ago, but failed in total ;-(
I've recently created a test fixture for the OracleAdapter and noticed that Oracle is behaving unexpectedly in many
situations. Not all these situations are common, though. I know of users that have CDO on Oracle for some years already
and are happy with it.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 15.11.2013 16:34, schrieb Leonid Ripeynih:
> Hi there!
>
> I've triesd to run CDO on Oracle DB and run into a following bug (feature?)
>
> Here, org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractFeatureMapTableMapping, in the following code:
>
> ..
> else
> {
> stmt.setNull(column++, getDBTypes().get(i).getCode());
> }
>
>
> It tries to set null to column with BOOLEAN type (getCode() returns 16). It's not possible in Oracle, one should use
> Types.BIT.
>
> Here is the similar bug, fixed in Hibernate: https://hibernate.atlassian.net/browse/HHH-6759
>
> Question is:
> Can it be fixed in OracleDbAdapter? I have little to no experience with net4j DB framework, and didn't find (yet) how
> to override it.
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
| Re: [CDO] Oracle: Writing null to boolean value probably should use Types.BIT instead if Types.BOOLE [message #1188471 is a reply to message #1188373] |
Fri, 15 November 2013 16:57 |
|
Am 15.11.2013 16:58, schrieb Leonid Ripeynih:
> Eike,
> I have a large model, which is mostly (like 90%) based on FeatureMap's. I've ran a CDO on H2, bumped into some bugs
> with feature map persistence, but it seems I overcame it (by some relatively minor fixes in org.eclipse.emf.cdo and
> org.eclipse.emf.cdo.common).
>
> Now it saves and loads fine.
>
> I'd like to know you senior commentary on which is better - to move our model from feature maps, or to contribute to
> CDO support for feature maps? Both are comparably large undertakings. But what I've bumped and fixed to is probably
> just the tip of the iceberg, so I would like to know what do you mean by 'but failed in total'. Is it just a bunch of
> relatively minor bugs, or some major design/code problems which prevent feature maps from being supported in current
> CDO version?
Our attempts are probably more than six years ago. I vaguely remember that their support in CDO is quite cross cutting
and added another dimension to the space of optional but combinable functions of CDO. The underlying cause may be the
lack of a CDO analogy of EStructuralFeature.Setting with its thousand implementations that manage the different access
patterns in central places. So yes, I would say it's a design issue, not just a number of smaller bugs.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02465 seconds
] 
Search
Help
Register
Login
Home
