Hi Ailish,
all comments based on latest version from SVN OJB_1_0_RELEASE branch. If
possible please test the upcoming version (read carefully the
release-notes before use ;-)).
To get the sources use a SVN-client with:
http://svn.apache.org/repos/asf/db/ojb/branches/OJB_1_0_RELEASE
Byrne, Ailish M wrote:
Hello,
We encountered a problem with the SequenceManagerTransientImpl. We have
two objects that are related; bank account has a bank on it. A key to
the bank account table has a custom FieldConversion implementation for
encryption/decryption associated with it. When we refresh the
references on a new bank account, OJB goes to retrieve the bank and uses
SequenceManagerTransientImpl to initialize any null keys on bank account
with a unique value. However, after SequenceManagerTransientImpl
returns a long > 1000, AbstractSequenceManager calls the sqlToJava
method on the custom FieldConversion (in the getUniqueLong method). The
custom FieldConversion bombs, because it's being asked to unencrypt and
already unencrypted value. So, we overrode getUniqueValue in
SequenceManagerTransientImpl as follows...
public Object getUniqueValue(FieldDescriptor field) throws
SequenceManagerException
{
return field.getJdbcType().sequenceKeyConversion(new
Long(getUniqueLong(field)));
// perform a sql to java conversion here, so that clients do
// not see any db specific values
// abyrne commented out: result =
field.getFieldConversion().sqlToJava(result);
// abyrne commented out: return result;
}
We would appreciate your feedback on whether or not this seems
problematic.
The conversion is already done in the super-class
http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/util/sequence/AbstractSequenceManager.java?view=markup
See method #getUniqueValue(...)
This method is called by OJB to lookup the next key.
Also, we have been trying to be diligent about reporting
issues to you and hope that we can get back on a standard OJB version
soon.
FYI, other issues that we have fixed in our custom 1.0.4 build and
reported to you are...
I have fixed all issues (see below), so OJB 1.0.5 should run without
patches. But upcoming 1.0.5 is more then a maintenance-release. Some new
methods added to the PB-api and a few internal interfaces are modified.
http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/release-notes.txt?view=markup
- "Out of the box OJB only supports CLOBs on DBCP, P6Spy, JBoss, or
vanilla JDBC connections. I had to modify their code to allow it to
unwrap PreparedStatements from XAPool prepared statements (which is the
library Workflow uses for JTA and XA)."
XAPool is now supported. The unwrap stuff is now separated in class
http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/util/UnwrapHelper.java?view=markup
also it's possible to add additional unwarp pattern at runtime.
- "MySQLPlatformImpl did not have support for the
StoredProcedureSequenceManagerImpl. This is fixed in OJB 1.0.5."
Add section about mysql here
http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/doc/forrest/src/documentation/content/xdocs/docu/guides/sequencemanager.xml?view=markup
Also, we recently tried to use the StoredProcedureSequenceManagerImpl
with Oracle, because we were working on MySQL compatibility for our app
and wanted to use the same sequence manager for both. We failed because
of invalid sql generated by
PlatformOracle9i.prepareNextValProcedureStatement.
Please report this bug to JIRA (if possible with stack trace)
http://issues.apache.org/jira/browse/OJB
regards,
Armin
Rather than fixing
this one, we opted to just keep using the SequenceManagerNextValImpl for
now.
Thanks,
Ailish
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
