Hi Bruno,
Bruno CROS wrote:
i already have patch torque3.1.1.jar. thanks for advice. I've done since
start with the build.xml of ojb-blank.jar (so torque).
I have the right database generated now. That's a good point and i thank you
all.
On the other hand, i have 2 database connections and it seems they do not
work anymore. Of course, i can't see any errors. I d'ont known how to spy DB
connections !!? shame, i known.
you can use p6spy
http://db.apache.org/ojb/docu/faq.html#traceProfileSQL
The particularity of one of these connections is that the database has been
made with 1.0.1 OJB release. Understand that this database is accessed by
my application, and by another one (bigger). So upgrading this DB is not so
suitable.
nevertheless, understand too, that my application need to be connected to
those two databses, mine in 1.0.4 and the big one in 1.0.1. At the same time
of course.
My doubts are about the repository_internal.xml ( describing OJB tables). If
these tables are not the same in the 2 DB. How could it work ??
Seems that the "default" connection doesn't require any of the internal
OJB tables (if you don't use odmg named objects or the specific List/Map
implementations).
"rushDb" use SequenceManagerHighLowImpl. In this case table OJB_HL_SEQ
is mandatory. The metadata mapping of this object/table changed between
1.0.1 and 1.0.4 but not the column names (one column was removed between
1.0.1 and 1.0.4). Thus you could try to use the "old" table with the
1.0.4 mapping. If this doesn't work you could drop and recreate table
OJB_HL_SEQ (OJB will automatically take care of existing id's and
re-populate the table).
In "rushDb" you are using useAutoCommit="0". In this case it's mandatory
that the jdbc-driver/DB disable the connection autoCommit property (else
you will run into problems with tx-rollback).
regards,
Armin
You understand what i mean when you see my repository.xml file. and the 2
next files, parts of it.
==================
my repository.xml file
=====================
<!ENTITY databaseMathieu SYSTEM "repository_database_mathieu.xml">
<!ENTITY databaseRushDb SYSTEM "repository_database_rushDb.xml">
<!ENTITY internal SYSTEM "repository_internal.xml">
<!ENTITY user SYSTEM "repository_user.xml">
<!ENTITY rushDb SYSTEM "repository_rushDb.xml">
]>
<descriptor-repository version="1.0"
isolation-level="read-uncommitted"
proxy-prefetching-limit="50">
<!-- connection Mathieu -->
&databaseMathieu;
<!-- connection rushDB -->
&databaseRushDb;
<!-- include ojb internal mappings here; comment this if you don't need
them -->
&internal;
<!-- mapping Mathieu -->
&user;
<!-- mapping RushDb -->
&rushDb;
==================================
repository_database_mathieu.xml
===================================
<!-- This connection is used as the default one within OJB -->
<jdbc-connection-descriptor
jcd-alias="default"
default-connection="true"
platform="Oracle9i"
jdbc-level="2.0"
driver="oracle.jdbc.driver.OracleDriver"
protocol="jdbc"
subprotocol="oracle"
dbalias="thin:@P615-5:1521:MATHIEU"
username="xxx"
password="xxxx"
batch-mode="false"
useAutoCommit="1"
ignoreAutoCommitExceptions="false"
>
<!--
On initialization of connections the ConnectionFactory change
the 'autoCommit'
state dependent of the used 'useAutoCommit' setting. This
doesn't work in all
situations/environments, thus for useAutoCommit="1" the
ConnectionFactory does
no longer set autoCommit to true on connection creation.
To use the old behavior (OJB version 1.0.3 or earlier) set this
property
to 'true', then OJB change the autoCommit state (if needed) of
new obtained connections at connection initialization to 'true'.
If 'false' or this property is removed, OJB don't try to change
connection
autoCommit state at connection initialization.
-->
<attribute attribute-name="initializationCheck"
attribute-value="false" />
<!-- alternative cache implementations, see docs section
"Caching" -->
<object-cache
class="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl">
<!-- meaning of attributes, please see docs section
"Caching" -->
<!-- common attributes -->
<attribute attribute-name="cacheExcludes" attribute-value=""/>
<!-- ObjectCacheTwoLevelImpl attributes -->
<attribute attribute-name="applicationCache"
attribute-value="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl"/>
<attribute attribute-name="copyStrategy"
attribute-value="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl$CopyStr
ategyImpl"/>
<attribute attribute-name="forceProxies"
attribute-value="false"/>
<!-- ObjectCacheDefaultImpl attributes -->
<attribute attribute-name="timeout" attribute-value="900"/>
<attribute attribute-name="autoSync" attribute-value="true"/>
<attribute attribute-name="cachingKeyType" attribute-value="0"/>
<attribute attribute-name="useSoftReferences"
attribute-value="true"/>
</object-cache>
<!-- For more info, see section "Connection Handling" in docs -->
<connection-pool
maxActive="30"
validationQuery=""
testOnBorrow="true"
testOnReturn="false"
whenExhaustedAction="0"
maxWait="10000">
<!-- Set fetchSize to 0 to use driver's default. -->
<attribute attribute-name="fetchSize" attribute-value="0"/>
<!-- Attributes with name prefix "jdbc." are passed directly to
the JDBC driver. -->
<!-- Example setting (used by Oracle driver when Statement
batching is enabled) -->
<attribute attribute-name="jdbc.defaultBatchValue"
attribute-value="5"/>
<!-- Attributes determining if ConnectionFactoryDBCPImpl
should also pool PreparedStatement. This is
programmatically disabled
when using platform=Oracle9i since Oracle statement caching
will conflict
with DBCP ObjectPool-based PreparepdStatement caching (ie
setting true
here has no effect for Oracle9i platform). -->
<attribute attribute-name="dbcp.poolPreparedStatements"
attribute-value="false"/>
<attribute attribute-name="dbcp.maxOpenPreparedStatements"
attribute-value="10"/>
<!-- Attribute determining if the Commons DBCP connection
wrapper will allow
access to the underlying concrete Connection instance from
the JDBC-driver
(normally this is not allowed, like in J2EE-containers
using wrappers). -->
<attribute
attribute-name="dbcp.accessToUnderlyingConnectionAllowed"
attribute-value="false"/>
</connection-pool>
<sequence-manager
className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl">
<attribute attribute-name="autoNaming" attribute-value="true"/>
</sequence-manager>
</jdbc-connection-descriptor>
<!-- Datasource example -->
<!-- jdbc-connection-descriptor
jcd-alias="default"
default-connection="true"
platform="Hsqldb"
jdbc-level="2.0"
jndi-datasource-name="java:DefaultDS"
username="sa"
password=""
batch-mode="false"
useAutoCommit="0"
ignoreAutoCommitExceptions="false"
>
Add the other elements like object-cache, connection-pool,
sequence-manager here.
</jdbc-connection-descriptor -->
==============================================
repository_database_rushDb.xml
==============================================
<!-- This connection is used as the default one within OJB -->
<jdbc-connection-descriptor
jcd-alias="rushDb"
default-connection="false"
platform="MsSQLServer"
jdbc-level="2.0"
driver="com.microsoft.jdbc.sqlserver.SQLServerDriver"
protocol="JDBC"
subprotocol="microsoft:sqlserver"
dbalias="//xxx.x.x.x:xxxx"
username="xxx"
password="xxxx"
batch-mode="true"
useAutoCommit="0"
ignoreAutoCommitExceptions="true"
>
<!--
On initialization of connections the ConnectionFactory change
the 'autoCommit'
state dependent of the used 'useAutoCommit' setting. This
doesn't work in all
situations/environments, thus for useAutoCommit="1" the
ConnectionFactory does
no longer set autoCommit to true on connection creation.
To use the old behavior (OJB version 1.0.3 or earlier) set this
property
to 'true', then OJB change the autoCommit state (if needed) of
new obtained connections at connection initialization to 'true'.
If 'false' or this property is removed, OJB don't try to change
connection
autoCommit state at connection initialization.
-->
<attribute attribute-name="initializationCheck"
attribute-value="false" />
<!-- alternative cache implementations, see docs section
"Caching" -->
<object-cache
class="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl">
<!-- meaning of attributes, please see docs section
"Caching" -->
<!-- common attributes -->
<attribute attribute-name="cacheExcludes" attribute-value=""/>
<!-- ObjectCacheTwoLevelImpl attributes -->
<attribute attribute-name="applicationCache"
attribute-value="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl"/>
<attribute attribute-name="copyStrategy"
attribute-value="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl$CopyStr
ategyImpl"/>
<attribute attribute-name="forceProxies"
attribute-value="false"/>
<!-- ObjectCacheDefaultImpl attributes -->
<attribute attribute-name="timeout" attribute-value="900"/>
<attribute attribute-name="autoSync" attribute-value="true"/>
<attribute attribute-name="cachingKeyType" attribute-value="0"/>
<attribute attribute-name="useSoftReferences"
attribute-value="true"/>
</object-cache>
<!-- For more info, see section "Connection Handling" in docs -->
<connection-pool
maxActive="30"
validationQuery=""
testOnBorrow="true"
testOnReturn="false"
whenExhaustedAction="0"
maxWait="10000">
<!-- Set fetchSize to 0 to use driver's default. -->
<attribute attribute-name="fetchSize" attribute-value="0"/>
<!-- Attributes with name prefix "jdbc." are passed directly to
the JDBC driver. -->
<!-- Example setting (used by Oracle driver when Statement
batching is enabled) -->
<attribute attribute-name="jdbc.defaultBatchValue"
attribute-value="5"/>
<!-- Attributes determining if ConnectionFactoryDBCPImpl
should also pool PreparedStatement. This is
programmatically disabled
when using platform=Oracle9i since Oracle statement caching
will conflict
with DBCP ObjectPool-based PreparepdStatement caching (ie
setting true
here has no effect for Oracle9i platform). -->
<attribute attribute-name="dbcp.poolPreparedStatements"
attribute-value="false"/>
<attribute attribute-name="dbcp.maxOpenPreparedStatements"
attribute-value="10"/>
<!-- Attribute determining if the Commons DBCP connection
wrapper will allow
access to the underlying concrete Connection instance from
the JDBC-driver
(normally this is not allowed, like in J2EE-containers
using wrappers). -->
<attribute
attribute-name="dbcp.accessToUnderlyingConnectionAllowed"
attribute-value="false"/>
</connection-pool>
<!-- alternative sequence manager implementations, see "Sequence
Manager" guide -->
<sequence-manager
className="org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl">
<!-- attributes supported by SequenceManagerHighLowImpl,
SequenceManagerInMemoryImpl, SequenceManagerNextValImpl
please see "Sequence Manager" guide or/and javadoc of class for
more information -->
<attribute attribute-name="seq.start" attribute-value="200000"/>
<attribute attribute-name="autoNaming" attribute-value="true"/>
<!-- attributes supported by SequenceManagerHighLowImpl
please see "Sequence Manager" guide or/and javadoc of classes
for more information -->
<attribute attribute-name="grabSize" attribute-value="20"/>
<!-- optional attributes supported by SequenceManagerNextValImpl
(support depends
on the used database), please see "Sequence Manager" guide
or/and javadoc of
classes for more information -->
<!-- attribute attribute-name="seq.as"
attribute-value="INTEGER"/ -->
<!-- attribute attribute-name="seq.incrementBy"
attribute-value="1"/ -->
<!-- attribute attribute-name="seq.maxValue"
attribute-value="999999999999999999999999999"/ -->
<!-- attribute attribute-name="seq.minValue"
attribute-value="1"/ -->
<!-- attribute attribute-name="seq.cycle"
attribute-value="false"/ -->
<!-- attribute attribute-name="seq.cache"
attribute-value="20"/ -->
<!-- attribute attribute-name="seq.order"
attribute-value="false"/ -->
</sequence-manager>
</jdbc-connection-descriptor>
<!-- Datasource example -->
<!-- jdbc-connection-descriptor
jcd-alias="default"
default-connection="true"
platform="Hsqldb"
jdbc-level="2.0"
jndi-datasource-name="java:DefaultDS"
username="sa"
password=""
batch-mode="false"
useAutoCommit="0"
ignoreAutoCommitExceptions="false"
>
Add the other elements like object-cache, connection-pool,
sequence-manager here.
</jdbc-connection-descriptor -->
On 2/3/06, Thomas Dudziak <[EMAIL PROTECTED]> wrote:
On 2/3/06, Bruno CROS <[EMAIL PROTECTED]> wrote:
i 'm afraid i need to repatch distributed torque-gen-3.1.1.jar to have
TIMESTAMP jdbc type created for java.sql.Date and java.sql.timestampas i
wrote in an old old post. (specific to oracle 9i and older )
You might want to try DdlUtils (http://db.apache.org/ddlutils ) instead
of Torque, it uses the same schema format and contains an Oracle9 (and
an Oracle10 one) platform that can use TIMESTAMP.
Tom
---------------------------------------------------------------------
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]
