Is Kodo Datastore Identity toString URL safe?

Hey Kodo,
The question is simple, can I be guaranteed that the String returned from
JDOHelper.getObjectId(obj).toString() is safe to be put in a querystring?
Now I don't mean in all JDO implementations, I haven't read it's required,
but does Kodo guarantee this?
Grtz,
Martin van Dijken

The question is simple, can I be guaranteed that the String returned
from JDOHelper.getObjectId(obj).toString() is safe to be put in a
querystring? Now I don't mean in all JDO implementations, I haven't read
it's required, but does Kodo guarantee this?What is a 'querystring'? An HTML CGI query string? If so, the answer is
'yes'... though if you want an all-purpose solution you should just
URLEncoder.encode() any values you want to appear in a query string.

Similar Messages

O/R mapping and datastore identity

Hi all,
we are currently trying to map an existing database schema to JDO. We have
not been able to map "correctly" to the existing schema in two
different cases. Any input that you may have to us on this is highly
appreciated.
Inheritance with indicators
In one part of the model, we use a single character indicator to
distinguish between which concrete class is to be instantiated. We
thus have a table A with columns:
type varchar2(1)
id number(10)
Other tables relate to this table. Some tables can only relate to some
types. To ensure that the relational model
expresses the correct constraints about which objects can relate to
one another, all our foreign keys include both the type and the
id. Still, the id is taken from a sequence and should be considered
datastore identity.
When mapping this to Kodo JDO, we cannot make (type,id) the primary
key and have datastore identity. We have had to compromise and use
just the id as the primary key (which is in fact unique "by
convention"). This in turn means that we cannot use (type,id) as the
reference from other tables (e.g. B), since a lookup from A to B then
includes the A table in the SQL fired just to get the correct type.
Are we missing something here? I would assume that this would be a
normal problem if using datastore identity and flat inheritance
mapping. And in fact, Kodo must know the value of the type for any A
object, since it has the instance and can simply relate the class to
the type through the metadata (however, this only partly solves the
problem). Is there a workaround we can use? Can we extend the primary
key/reference support to support this ourselves?
Sub-objects
In another part of our model, we have a table C where each record can
have a number of records in a table D:
C:
id number(10)
D:
id number(10)
Cid number(10) (references C.id)
In the database, the primary key for D is (id, Cid). id is drawn from
a sequence and is thus unique "by convention". Other tables relate to
D through (id, Cid), thus we will need a unique index on this.
Again, we have had to make id the primary key of D and let all
relations to it only join on the id field when doing the mapping.
We are reluctant to introduce new indexes in the database since this
will be harmful to our import performance.
Is there a workaround for this, or are we simply not doing this
correctly??

Inheritance with indicators
---------------------------If the type column is part of the primary key, I would suggest using application
identity. You can use extensions like sequence-assigned to still have the id
value auto-assigned.
Sub-objects
-----------Again, I would use application identity.

Exposing pk field in Datastore Identity

Hi all,
I was wondering what people's views are on the following -
Datastore Identity hides the identity value of objects but there are
cetainly cases where it would be very useful to obtain the PK id as it is in
the database. My concrete example is we are currently migrating an
application from "legacy" JDBC to JDO and several areas currently require us
to convert JDO id classes/strings to simple integer ids and back again (at
least temporarily until the migration is complete).
Is it definitely "against the rules" to expose the primary key column in the
database table as a simple property of the bean? So long as the application
ensures this id is read-only (no public injector method) can this work?
Thanks in advance,
Simon

While it may work, I don't think its any less vendor-specific than using
a MyJDOHelper class which can break the String down/casting it to
ObjectIds.Id, and far less prone to something weird going on.
The other alternative is to use Application Identity which inherently
exposes PK fields to whatever you desire.
Simon Horne wrote:
ah, but could I actually avoid this vendor specific parsing by exposing the
id field and mapping it through jdo?
Simon
"Stephen Kim" <[email protected]> wrote in message
news:b403bg$c0l$[email protected]..
While not necessarily the most vendor neutral (since you need tocast/parse the oid object), there is nothing inherently wrong with that
method... just be aware of when the identity value is assigned (e.g.
jdoPostLoad (), makePersistent (), etc..)
On Mon, 03 Mar 2003 10:17:02 +0000, Simon Horne wrote:
Hi all,
I was wondering what people's views are on the following -
Datastore Identity hides the identity value of objects but there are
cetainly cases where it would be very useful to obtain the PK id as it
is in
the database. My concrete example is we are currently migrating an
application from "legacy" JDBC to JDO and several areas currentlyrequire us
to convert JDO id classes/strings to simple integer ids and back again(at
least temporarily until the migration is complete).
Is it definitely "against the rules" to expose the primary key column inthe
database table as a simple property of the bean? So long as theapplication
ensures this id is read-only (no public injector method) can this work?
Thanks in advance,
Simon--
Stephen Kim
[email protected]
SolarMetric, Inc.
http://www.solarmetric.com
Stephen Kim
[email protected]
SolarMetric, Inc.
http://www.solarmetric.com

Inheritance using datastore identity

I have issue with the name of database columns.
I have inheritance between two classes stored in there own tables.
The Database primary key column name for Action is ActionID
and for Process is ProcessID.
If I run the schematool with the refresh option then
the tool add actionid, drops processid from the PROCESS table
This is not acceptable.
The class, table and jdo definition are listed below.
Can anybody suggest the correct extension tags so that I can retain
the original database column names?
Thanks
Paresh
Following are my classes and corresponding table
class Action {
private String actionName;
class Process extends Action {
private String processDescription;
Table ACTION
Field ACTIONID PK
Field ACTIONNAME
TABLE PROCESS
FIELD PROCESSID PK
FIELD PROCESSDESCRIPTION
PROCESS.PROCESSID has a foreign key relation with ACTION.ACTIONID
The jdo file is as follows
<package name="sample">
<class name="Action">
<extension vendor-name="kodo" key="class-column" value="none"/>
<extension vendor-name="kodo" key="pk-column"
value="ACTIONID"/>
<extension vendor-name="kodo" key="lock-column" value="none"/>
<extension vendor-name="kodo" key="table" value="ACTION"/>
<field name="actionName">
<extension vendor-name="kodo" key="data-column"
value="ACTIONNAME"/>
</field>
</class>
<class name="Process" persistence-capable-superclass="Action">
<extension vendor-name="kodo" key="pk-column"
value="PROCESSID"/>
<extension vendor-name="kodo" key="table" value="PROCESS"/>
<field name="processDescription" >
<extension vendor-name="kodo" key="data-column"
value="PROCESSDESCRIPTION"/>
</field>
</class>
</package>
</jdo>

Kodo 2.5 RC1 is currently available on our website:
http://solarmetric.com/Software/beta/2.5.0
We anticipate releasing Kodo 2.5 RC2 in the next day or so. We had
intended to release RC2 today, but some internal machine failures have
slowed down our integration testing for RC2, so things have been delayed
a bit. There are only a couple of small known outstanding issues standing
between the release of RC2 and a final 2.5.0 release. So, I would not be
surprised if 2.5.0 were released in the next week to 10 days. But this is
just a guess; this is by no means a commitment to a release date. As a
general rule, we do not commit to release dates, as unforseen delays can
always crop up at the last minute.
-Patrick
On Thu, 22 May 2003 07:25:46 -0400, Paresh wrote:
What is the release date for Kodo 2.5
Patrick Linskey wrote:
In Kodo 2.4, one limitation of multiple-table inheritance mappings is
that the PK columns must have the same names. This is not the case with
2.5.
-Patrick
On Mon, 19 May 2003 13:47:55 -0400, Paresh wrote:
I have issue with the name of database columns.
I have inheritance between two classes stored in there own tables.
The Database primary key column name for Action is ActionID and for
Process is ProcessID.
If I run the schematool with the refresh option then the tool add
actionid, drops processid from the PROCESS table This is not
acceptable.
The class, table and jdo definition are listed below.
Can anybody suggest the correct extension tags so that I can retain
the original database column names?
Thanks
Paresh
Following are my classes and corresponding table
class Action {
private String actionName;
class Process extends Action {
private String processDescription;
Table ACTION
Field ACTIONID PK
Field ACTIONNAME
TABLE PROCESS
FIELD PROCESSID PK
FIELD PROCESSDESCRIPTION
PROCESS.PROCESSID has a foreign key relation with ACTION.ACTIONID
The jdo file is as follows
<package name="sample">
<class name="Action">
<extension vendor-name="kodo" key="class-column"
value="none"/> <extension vendor-name="kodo"
key="pk-column"
value="ACTIONID"/>
<extension vendor-name="kodo" key="lock-column"
value="none"/> <extension vendor-name="kodo" key="table"
value="ACTION"/> <field name="actionName">
<extension vendor-name="kodo" key="data-column"
value="ACTIONNAME"/>
</field>
</class>
<class name="Process"
persistence-capable-superclass="Action">
<extension vendor-name="kodo" key="pk-column"
value="PROCESSID"/>
<extension vendor-name="kodo" key="table"
value="PROCESS"/> <field name="processDescription" >
<extension vendor-name="kodo" key="data-column"
value="PROCESSDESCRIPTION"/>
</field>
</class>
</package>
</jdo>
Patrick Linskey
SolarMetric Inc.
Patrick Linskey
SolarMetric Inc.

Database identity...

Hello!
Could any one give me example, how to use a database identity?
Could a database identity be an Integer type?
I'm setting a objectid-class="java.lang.Integer", than refresh a schema,
save an object and get it objectID - myclass-1250 for example...
how i'm could get a 1250 and than call persitManager.getObjectByID(new
Integer(1250))?
Help please!!!

First do -not- set objectid-class to Integer. In fact, with datastore
identity, you should not set that attribute that at all. The rules for object id
classes are quite stringent:
http://solarmetric.com/Software/Documentation/2.4.3/docs/jdo_overview_pc_identity.html#jdo_overview_pc_identity_datastore
With datastore identity, from a portability perspective, you should not be
dealing with the individual primary key components. Instead you should be
using the toString () and pm.newObjectIdInstance () methods to manage your
identity or maintain it in a java.lang.Object reference.
However you can easily create an object id instance using our public
object id constructors, i.e. new com.solarmetric.kodo.util.ObjectIds.Id
(1250, myclass.class);
http://solarmetric.com/Software/Documentation/2.4.3/docs/javadoc/com/solarmetric/kodo/util/ObjectIds.Id.html
However, we do provide
On Mon, 05 May 2003 06:08:44 +0000, Vladimir wrote:
Hello!
Could any one give me example, how to use a database identity?
Could a database identity be an Integer type?
I'm setting a objectid-class="java.lang.Integer", than refresh a schema,
save an object and get it objectID - myclass-1250 for example...
how i'm could get a 1250 and than call persitManager.getObjectByID(new
Integer(1250))?
Help please!!!

Unit test fails after upgrading to Kodo 4.0.0 from 4.0.0-EA4

I have a group of 6 unit tests failing after upgrading to the new Kodo
4.0.0 (with BEA) from Kodo-4.0.0-EA4 (with Solarmetric). I'm getting
exceptions like the one at the bottom of this email. It seems to be an
interaction with the PostgreSQL driver, though I can't be sure. I
haven't changed my JDO configuration or the related classes in months
since I've been focusing on using the objects that have already been
defined. The .jdo, .jdoquery, and .java code are below the exception,
just in case there's something wrong in there. Does anyone have advice
as to how I might debug this?
Thanks,
Mark
Testsuite: edu.ucsc.whisper.test.integration.UserManagerQueryIntegrationTest
Tests run: 15, Failures: 0, Errors: 6, Time elapsed: 23.308 sec
Testcase:
testGetAllUsersWithFirstName(edu.ucsc.whisper.test.integration.UserManagerQueryIntegrationTest):
Caused an ERROR
The column index is out of range: 2, number of columns: 1.
<2|false|4.0.0> kodo.jdo.DataStoreException: The column index is out of
range: 2, number of columns: 1.
at
kodo.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4092)
at kodo.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:82)
at kodo.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:66)
at kodo.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:46)
at
kodo.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:176)
at
kodo.kernel.QueryImpl$PackingResultObjectProvider.handleCheckedException(QueryImpl.java:2460)
at
com.solarmetric.rop.EagerResultList.<init>(EagerResultList.java:32)
at kodo.kernel.QueryImpl.toResult(QueryImpl.java:1445)
at kodo.kernel.QueryImpl.execute(QueryImpl.java:1136)
at kodo.kernel.QueryImpl.execute(QueryImpl.java:901)
at kodo.kernel.QueryImpl.execute(QueryImpl.java:865)
at kodo.kernel.DelegatingQuery.execute(DelegatingQuery.java:787)
at kodo.jdo.QueryImpl.executeWithArray(QueryImpl.java:210)
at kodo.jdo.QueryImpl.execute(QueryImpl.java:137)
at
edu.ucsc.whisper.core.dao.JdoUserDao.findAllUsersWithFirstName(JdoUserDao.java:232)
at
edu.ucsc.whisper.core.manager.DefaultUserManager.getAllUsersWithFirstName(DefaultUserManager.java:252)
NestedThrowablesStackTrace:
org.postgresql.util.PSQLException: The column index is out of range: 2,
number of columns: 1.
at
org.postgresql.core.v3.SimpleParameterList.bind(SimpleParameterList.java:57)
at
org.postgresql.core.v3.SimpleParameterList.setLiteralParameter(SimpleParameterList.java:101)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.bindLiteral(AbstractJdbc2Statement.java:2085)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.setInt(AbstractJdbc2Statement.java:1133)
at
com.solarmetric.jdbc.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:390)
at
com.solarmetric.jdbc.PoolConnection$PoolPreparedStatement.setInt(PoolConnection.java:440)
at
com.solarmetric.jdbc.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:390)
at
com.solarmetric.jdbc.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:390)
at
com.solarmetric.jdbc.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:390)
at
com.solarmetric.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.setInt(LoggingConnectionDecorator.java:1
257)
at
com.solarmetric.jdbc.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:390)
at
com.solarmetric.jdbc.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:390)
at kodo.jdbc.sql.DBDictionary.setInt(DBDictionary.java:980)
at kodo.jdbc.sql.DBDictionary.setUnknown(DBDictionary.java:1299)
at kodo.jdbc.sql.SQLBuffer.setParameters(SQLBuffer.java:638)
at kodo.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:539)
at kodo.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:512)
at kodo.jdbc.sql.SelectImpl.execute(SelectImpl.java:332)
at kodo.jdbc.sql.SelectImpl.execute(SelectImpl.java:301)
at kodo.jdbc.sql.Union$UnionSelect.execute(Union.java:642)
at kodo.jdbc.sql.Union.execute(Union.java:326)
at kodo.jdbc.sql.Union.execute(Union.java:313)
at
kodo.jdbc.kernel.SelectResultObjectProvider.open(SelectResultObjectProvider.java:98)
at
kodo.kernel.QueryImpl$PackingResultObjectProvider.open(QueryImpl.java:2405)
at
com.solarmetric.rop.EagerResultList.<init>(EagerResultList.java:22)
at kodo.kernel.QueryImpl.toResult(QueryImpl.java:1445)
at kodo.kernel.QueryImpl.execute(QueryImpl.java:1136)
at kodo.kernel.QueryImpl.execute(QueryImpl.java:901)
at kodo.kernel.QueryImpl.execute(QueryImpl.java:865)
at kodo.kernel.DelegatingQuery.execute(DelegatingQuery.java:787)
at kodo.jdo.QueryImpl.executeWithArray(QueryImpl.java:210)
at kodo.jdo.QueryImpl.execute(QueryImpl.java:137)
at
edu.ucsc.whisper.core.dao.JdoUserDao.findAllUsersWithFirstName(JdoUserDao.java:232)
--- DefaultUser.java -------------------------------------------------
public class DefaultUser
implements User
/** The account username. */
private String username;
/** The account password. */
private String password;
/** A flag indicating whether or not the account is enabled. */
private boolean enabled;
/** The authorities granted to this account. */
private Set<Authority> authorities;
/** Information about the user, including their name and text that
describes them. */
private UserInfo userInfo;
/** The set of organizations where this user works. */
private Set<Organization> organizations;
--- DefaultUser.jdo --------------------------------------------------
<?xml version="1.0"?>
<!DOCTYPE jdo PUBLIC
"-//Sun Microsystems, Inc.//DTD Java Data Objects Metadata 2.0//EN"
"http://java.sun.com/dtd/jdo_2_0.dtd">
<jdo>
<package name="edu.ucsc.whisper.core">
<sequence name="user_id_seq"
factory-class="native(Sequence=user_id_seq)"/>
<class name="DefaultUser" detachable="true"
table="whisper_user" identity-type="datastore">
<datastore-identity sequence="user_id_seq" column="userId"/>
<field name="username">
<column name="username" length="80" jdbc-type="VARCHAR" />
</field>
<field name="password">
<column name="password" length="40" jdbc-type="CHAR" />
</field>
<field name="enabled">
<column name="enabled" />
</field>
<field name="userInfo" persistence-modifier="persistent"
default-fetch-group="true" dependent="true">
<extension vendor-name="jpox"
key="implementation-classes"
value="edu.ucsc.whisper.core.DefaultUserInfo" />
<extension vendor-name="kodo"
key="type"
value="edu.ucsc.whisper.core.DefaultUserInfo" />
</field>
<field name="authorities" persistence-modifier="persistent"
table="user_authorities"
default-fetch-group="true">
<collection
element-type="edu.ucsc.whisper.core.DefaultAuthority" />
<join column="userId" delete-action="cascade"/>
<element column="authorityId" delete-action="cascade"/>
</field>
<field name="organizations" persistence-modifier="persistent"
table="user_organizations" mapped-by="user"
default-fetch-group="true" dependent="true">
<collection
element-type="edu.ucsc.whisper.core.DefaultOrganization"
dependent-element="true"/>
<join column="userId"/>

</field>
</class>
</package>
</jdo>
--- DefaultUser.jdoquery ---------------------------------------------
<?xml version="1.0"?>
<!DOCTYPE jdo PUBLIC
"-//Sun Microsystems, Inc.//DTD Java Data Objects Metadata 2.0//EN"
"http://java.sun.com/dtd/jdo_2_0.dtd">
<jdo>
<package name="edu.ucsc.whisper.core">
<class name="DefaultUser">
<query name="UserByUsername"
language="javax.jdo.query.JDOQL"><![CDATA[
SELECT UNIQUE FROM edu.ucsc.whisper.core.DefaultUser
WHERE username==searchName
PARAMETERS java.lang.String searchName
]]></query>
<query name="DisabledUsers"
language="javax.jdo.query.JDOQL"><![CDATA[
SELECT FROM edu.ucsc.whisper.core.DefaultUser WHERE
enabled==false
]]></query>
<query name="EnabledUsers"
language="javax.jdo.query.JDOQL"><![CDATA[
SELECT FROM edu.ucsc.whisper.core.DefaultUser WHERE
enabled==true
]]></query>
<query name="CountUsers"
language="javax.jdo.query.JDOQL"><![CDATA[
SELECT count( this ) FROM edu.ucsc.whisper.core.DefaultUser
]]></query>
</class>
</package>
</jdo>

I'm sorry, I have no idea. I suggest sending a test case that
reproduces the problem to support.

HSQL DB Identity & Auto Increment

We are trying to write records to this table:
create table location_groups
group_id identity
,jdoversion integer
,jdoclass varchar(255) default 'path.impl.LocationGroup' not null
,group_name varchar(100) not null
,group_parent_id integer
Package.jdo is:
<package name="path">
<class name="LocationComponent">
</class>
</package>
<package name="path.impl">
<class name="LocationGroup" persistence-capable-superclass="path.LocationComponent">

<extension vendor-name="kodo" key="jdbc-auto-increment" value="true"/>
<field name="children" persistence-modifier="persistent" default-fetch-group="true">
<collection element-type="path.impl.Location"/>
</field>
</class>
and package.mapping is:
<package name="path">
<class name="LocationComponent">
<jdbc-class-map type="horizontal"/>
</class>
</package>
<package name="path.impl">
<class name="LocationGroup">
<jdbc-class-map type="base" pk-column="GROUP_ID" table="LOCATION_GROUPS"/>
<jdbc-version-ind type="version-number" column="JDOVERSION"/>
<jdbc-class-ind type="in-class-name" column="JDOCLASS"/>
<field name="path.LocationComponent.name">
<jdbc-field-map type="value" column="GROUP_NAME"/>
</field>
<field name="children">
<jdbc-field-map type="one-many" table="LOCATIONS" ref-column.GROUP_ID="GROUP_PARENT_ID"/>
</field>
</class>
</package>
I have tried all manner of configurations but the error remains the same:
25-Apr-2008 16:05:24 com.ea.albt.infrastructure.persistence.jdo.JDODataStore BeginTransaction
CONFIG: Starting transaction
25-Apr-2008 16:05:24 com.ea.albt.infrastructure.persistence.jdo.JDODataStore updateObjects
FINE: Updating object ALBT Loc1209135924484 (has not yet been persisted)
25-Apr-2008 16:05:25 com.ea.albt.infrastructure.persistence.jdo.JDODataStore updateObjects
WARNING: Failed to persist/update objectALBT Loc1209135924484
kodo.util.FatalDataStoreException: Attempt to update the sequence table "JDO_SEQUENCE" failed. The sequence table is typically created when you run the mappingtool's refresh action on any datastore identity class. If you have not run the mappingtool but want to create the sequence table, run:
java kodo.jdbc.schema.DBSequenceFactory -action add
NestedThrowables:
Why is Kodo trying to use the jdo_sequence table when we want it to use the HSQLdb identity field ?

We have many users using single field identity and auto-increment together.

Kodo 4.1.2 download incomplete?

The current Kodo documentation states that internally, Kodo still uses the kodo.util.Id class for datastore identity. None of the JAR files in the Kodo 4.1.2 distribution I just downloaded contains this class. This was first evident to me when attempting to build my application against the Kodo 4.1.2 JARs; I saw a huge list of compilation errors.
Plesae advise.
Thanks,
Brian

Turns out that the kodo.util.Id class has been deprecated and replaced with org.apache.openjpa.util.Id. Unfortunately the current documentation that ships with the Kodo 4.1.2 distribution is out-of-date, as it incorrectly states that Kodo still uses the kodo.util.Id internally to manage datastore identity. Bottom line, anyone using Kodo 4.1.2 should use org.apache.openjpa.util.Id when dealing with datastore identity ID objects.

Datastore id and flat class mapping

Hi,
I have
- an abstract persistent class A with 2 concrete persistent subclasses A1
and A2. I'm using datastore identity and flat class mapping.
- a class B that has a field fb with a one-many mapping to A1 objects
(Hashset).
- a class C that has a field fc with a one-many mapping to A objects
(Hashset).
- an instance a1 of A1 (id = 5)
- an instance b of B in which fb contains a1
- an instance c of C in which fc contains a1
When loading b and then c, i happen to have 2 instances representing a1 in
the same persistent manager. the one loaded in b has A1-5 as ObjectId and
the one loaded in c has A-5 as ObjectId. Thus those two objects have a
different object id while they represents the same data.
I would expect to find only one.
Do you have any idea ?
Thanks,
Laurent Czinczenheim

I found the problem! There is no more jdo-1.0.1.jar in the kodo rar :-)
Czinczenheim wrote:
I have only kodo in the rar. If i put the kodo rar 3.1.3, i can deploy it.
if i put the kodo rar 3.2.0, i cannot and get the previous exception. Is
there any difference in the packages used by kodo 3.2.0 (other than kodo
packages) that could interfer with the one i could have in my jboss lib
directories ?
thanks
laurent
Stephen Kim wrote:
Kodo should either not be in the classpath and only in the rar or
viceversa. It still seems like a classpath issue. Can you inspect your
kodo-jdo-runtime.jars for the existence of kodo/util/FatalUserException?
Czinczenheim wrote:
I have only one version of Kodo in my classpath. Therefore, when i
replace
the rar by the one from version 3.1.3 (or any older version), i don'thave
any problem to deploy the kodo resource adapter.
Stephen Kim wrote:
It appears that you may be having classpath problems. Do you have
multiple versions of Kodo in the classpath or ear/rar?
Czinczenheim wrote:
Marc,
i wanted to try it with the new 3.2 beta version but i can't even deploy
kodo 3.2.b1 in JBoss 3.2.3. Here is the stacktrace i get when deploying
the rar (My kodo-ds.xml is the same as the one i used with kodo 3.1.3):
11:47:52,975 INFO [RARDeployment] Starting
11:47:53,036 WARN [ServiceController] Problem starting service
jboss.jca:service=ManagedConnectionFactory,name=jdo/pmf/prisma01
java.lang.NoClassDefFoundError: kodo/util/FatalUserException
     at java.lang.Class.getDeclaredConstructors0(Native Method)
     at java.lang.Class.privateGetDeclaredConstructors(Class.java:1610)
     at java.lang.Class.getConstructor0(Class.java:1922)
     at java.lang.Class.newInstance0(Class.java:278)
     at java.lang.Class.newInstance(Class.java:261)
     at
org.jboss.resource.connectionmanager.RARDeployment.startService(RARDeployment.java:533)
>>>
     at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
     at java.lang.reflect.Method.invoke(Method.java:324)
     at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>>>
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
     at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:976)
>>>
     at $Proxy12.start(Unknown Source)
     at org.jboss.system.ServiceController.start(ServiceController.java:394)
     at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
     at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
     at java.lang.reflect.Method.invoke(Method.java:324)
     at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>>>
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
     at $Proxy4.start(Unknown Source)
     at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
     at java.lang.reflect.Method.invoke(Method.java:324)
     at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>>>
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
     at
org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:177)
     at $Proxy18.start(Unknown Source)
     at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:231)
     at org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:632)
     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:605)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
     at java.lang.reflect.Method.invoke(Method.java:324)
     at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>>>
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
     at $Proxy6.deploy(Unknown Source)
     at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:302)
>>>
     at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:476)
>>>
     at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:201)
>>>
     at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:274)
>>>
     at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192)
     at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
     at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
     at java.lang.reflect.Method.invoke(Method.java:324)
     at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>>>
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
     at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:976)
>>>
     at $Proxy0.start(Unknown Source)
     at org.jboss.system.ServiceController.start(ServiceController.java:394)
     at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
     at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
     at java.lang.reflect.Method.invoke(Method.java:324)
     at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>>>
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
     at $Proxy4.start(Unknown Source)
     at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226)
     at org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:632)
     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:605)
     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:589)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
     at java.lang.reflect.Method.invoke(Method.java:324)
     at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>>>
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
     at $Proxy5.deploy(Unknown Source)
     at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:384)
     at org.jboss.system.server.ServerImpl.start(ServerImpl.java:291)
     at org.jboss.Main.boot(Main.java:150)
     at org.jboss.Main$1.run(Main.java:388)
     at java.lang.Thread.run(Thread.java:534)
Thanks for your help since the initial bug i described is critical forus.
Laurent
Marc Prud'hommeaux wrote:
Laurent-
I believe I have seen that problem, but I can't recall the exact
symptoms (or the exact bug number). However, I do think that it was
fixed for Kodo 3.2. Can you download the 3.2 beta and see if the
problem
still occurs?
If it does still happen, can you provide us with your .jdo, .mapping,
and .java files for the classes so we can take a look?
In article <[email protected]>, Czinczenheim wrote:
Hi,
I have
- an abstract persistent class A with 2 concrete persistent subclasses
A1
and A2. I'm using datastore identity and flat class mapping.
- a class B that has a field fb with a one-many mapping to A1 objects
(Hashset).
- a class C that has a field fc with a one-many mapping to A objects
(Hashset).
- an instance a1 of A1 (id = 5)
- an instance b of B in which fb contains a1
- an instance c of C in which fc contains a1
When loading b and then c, i happen to have 2 instances representing
a1
in
the same persistent manager. the one loaded in b has A1-5 as ObjectIdand
the one loaded in c has A-5 as ObjectId. Thus those two objects have a
different object id while they represents the same data.
I would expect to find only one.
Do you have any idea ?
Thanks,
Laurent Czinczenheim
Marc Prud'hommeaux
SolarMetric Inc.
Steve Kim
[email protected]
SolarMetric Inc.
http://www.solarmetric.com
Steve Kim
[email protected]
SolarMetric Inc.
http://www.solarmetric.com

Auto populating application identity primary key?

I'm sure this has been asked before but I couldn't find anything by many
searches.
I have some classes with int or long as their primary key. I prefer using
application identity so the application can have direct access to the
primary key.
I would like to have the primary key automatically populated by Kodo from
a sequence such that I can do:
MyObject test = new MyObject();
pm.makePersistent(test);
assertTrue(test.getId() > 0);
Is this possible in Kodo? I haven't been able to find it. I know I can do
it with datastore identity but I would really like to avoid that.
Thank you,
Joel Shellman

Hi Joel,
before you may consider to use auto-incremented appid PK's let me tell
some things from my own experience.
If you have auto-incremented primary key fields you have consider that
their values will be finally set when you commit the transaction.
So if you access the pk fields during a transaction their values will be
NOT set until you call explicitly KodoPersistenceManager.flush() or commit
the transaction.
If you use applications identity and if you have a compound PK's which one
its fields presents a foreign key from a relation, you have to consider
this behavior and maybe run into problems.
I had many problems with it and finally build a wrapper around the
sequence generator instance from KodoHelper.getSequenceHelper ().
Greetings,
Matthias
Stephen Kim wrote:
Joel, there is not, unless you are using auto-incrementing primary keys.
You can do it in application code by calling
KodoHelper.getSequenceHelper (). Note that you should not have this in
an empty constructor as it may interfere with integration with JDO's
registration system.
Joel Shellman wrote:
I'm sure this has been asked before but I couldn't find anything by many
searches.
I have some classes with int or long as their primary key. I prefer using
application identity so the application can have direct access to the
primary key.
I would like to have the primary key automatically populated by Kodo from
a sequence such that I can do:
MyObject test = new MyObject();
pm.makePersistent(test);
assertTrue(test.getId() > 0);
Is this possible in Kodo? I haven't been able to find it. I know I can do
it with datastore identity but I would really like to avoid that.
Thank you,
Joel Shellman
Steve Kim
[email protected]
SolarMetric Inc.
http://www.solarmetric.com

Kodo JDO 2.3.4 now available

All,
Kodo JDO 2.3.4 is now available at http://www.solarmetric.com/. This release
contains a number of bugfixes and a couple enhancements to the reverse
schema tool.
New features
* The schema generator can now accept a list of tables to generate.
* The reverse mapping tool has additional options for using foreign
key names to generate relation names, generating primitive wrapper-type
fields if a column is nullable, and allowing primary keys on many-to-many
join tables.
Bugfixes
* Fixed problems with many-to-many relations between tables that use
vertical inheritance.
* Fixed bug in schematool that caused it to not generate primary key
columns in subclass tables when using datastore identity + custom
names + vertical inheritance.
* Fixed serp library conflict between reverse mapping tool and main Kodo
libraries.
* Fixed a reverse mapping tool bug in which column names that conflicted with
Java keywords would result in the generation of uncompilable Java classes.
* Fixed problem that caused read-only flag to be ignored in many-to-many
relations.
* Multi-table inheritance deletes are now performed from the leaf table
in the inheritance chain up to the base table. Inserts are performed
from the base table down to the leaf. This supports the common
referential integrity model of establishing a foreign key relation
from inherited tables to their parent tables.
Enjoy!
-Patrick
Patrick Linskey [email protected]
SolarMetric Inc. http://www.solarmetric.com

An email will be sent out to owners of the query extension or caching
plugins sometime today (Tuesday).
You'll all be thrilled to hear that our spiffy new licensing system in
2.4 will not require multiple jars, which will make life easier for people
with plugins when upgrades are released.
-Patrick
In article <[email protected]>, Alex Roytman wrote:
Could you please post query extensions for 2.3.4
"Patrick Linskey" <[email protected]> wrote in message
news:[email protected]...
All,
Kodo JDO 2.3.4 is now available at http://www.solarmetric.com/. This
release
contains a number of bugfixes and a couple enhancements to the reverse
schema tool.
New features
* The schema generator can now accept a list of tables to generate.
* The reverse mapping tool has additional options for using foreign
key names to generate relation names, generating primitive wrapper-type
fields if a column is nullable, and allowing primary keys onmany-to-many
join tables.
Bugfixes
* Fixed problems with many-to-many relations between tables that use
vertical inheritance.
* Fixed bug in schematool that caused it to not generate primary key
columns in subclass tables when using datastore identity + custom
names + vertical inheritance.
* Fixed serp library conflict between reverse mapping tool and main Kodo
libraries.
* Fixed a reverse mapping tool bug in which column names that conflictedwith
Java keywords would result in the generation of uncompilable Javaclasses.
* Fixed problem that caused read-only flag to be ignored in many-to-many
relations.
* Multi-table inheritance deletes are now performed from the leaf table
in the inheritance chain up to the base table. Inserts are performed
from the base table down to the leaf. This supports the common
referential integrity model of establishing a foreign key relation
from inherited tables to their parent tables.
Enjoy!
-Patrick
Patrick Linskey [email protected]
SolarMetric Inc. http://www.solarmetric.com
Patrick Linskey [email protected]
SolarMetric Inc. http://www.solarmetric.com

App identity w/ inheritance

This post is a repeat from the other forum. I'm having trouble using
inheritance (class-column and persistence-capable-superclass attrs) with
app identity. When I convert to datastore identity, Kodo correctly
gives me an instance of the subclass named in the class-column. When I
use app identity, it tries to create an instance of the superclass and
ignores the class-column. Is this a known issue, or am I just missing
something?
Jerry Pulley
Sr. Developer
Commerce Technologies, Inc.
21 Corporate Drive
Clifton Park, NY 12065
518.886.0700 x3876 Phone
518.886.0701 Fax

See answer in kodo.developer newsgroup.

Reverse Mapping: letting Kodo manage pk-column

Hi again,
i have a db with many predefined tables. Its not allowed to change the db
schema. The generated Java-classes are looking fine but i want to let kodo
manage the pk columns (like JDOIDX in generated tables). I dont want the
more technical pks in my business classes. Is it possible?
Any help is welcome!

Abe White wrote:
Adding a data store identity option to the reverse mapping tool is relatively
high on our to-do list, but it's not implemented yet. For now, you can
follow the steps in the documentation for reverse-mapping your classes, then
switch over to datastore identity manually by changing the class definitions
and metadata.Ok, this solution is workable. Will try it, thanks!

Getting datastore id

I wonder if there is a way to get datastore id in Java code.
I actually would like to benefit from id generation at database level.
If I map the datastore id to a field in the Java class, I get an error
when creating object reporting two values not in synch; which is
understandable.
Is there a way to fetch the datastore id (other than using direct JDBC),
or to declare a field as read-only ?
Regards,
J-F

J-F Daune wrote:
I wonder if there is a way to get datastore id in Java code.
I actually would like to benefit from id generation at database level.
If I map the datastore id to a field in the Java class, I get an error
when creating object reporting two values not in synch; which is
understandable.
Is there a way to fetch the datastore id (other than using direct JDBC),
or to declare a field as read-only ?
Regards,
J-F
Just what I did some days ago ...
If you use application identity you nevertheless can leave the task of
generating an id to kodo.
Chapter "5.2.4.3. Sequence-Assigned" of the manual is what solved my problem.
If you want to use datastore-identity and just sometimes want to know the
primary-key value, you can cast the ObjectId (JDOHelper.getObjectId) to
kodo.util.Id ... this one allows you to access the primary key as well.

ADF Security : identity store : tables in a SQL database

hi
The documentation says "ADF Security is built on top of the Oracle Platform Security Services (OPSS) architecture, which itself is well-integrated with Oracle WebLogic Server. ".
As such, ADF Security provides abstractions, also abstraction from an identity store (the repository of user identities and login credentials).
If my identity store is a set of custom tables in a SQL database, what are the Oracle supported options to use that identity store for an ADF application using ADF Security?
(Please refer to related documentation if possible.)
many thanks
Jan Vervecken

Thanks for your reply John.
John Stegeman wrote:
... To your questions to Frank - I'd answer "yes." ...Thanks for the confirmation.
... The specific points of the documentation that I found helpful were [url http://download.oracle.com/docs/cd/E21764_01/core.1111/e10043/underjps.htm#BABHCGGG]this picture and the discussion on identity management [url http://download.oracle.com/docs/cd/E21764_01/core.1111/e10043/addlsecfea.htm#CFHGBDEG]here. ...
The "Identity Management" section you refer to says ...
"... The domain administrator must configure the domain authenticator (with the Administration Console), update identities (enterprise users and groups) in the environment, as appropriate, and map application roles to enterprise users and groups (with Fusion Middleware Control). ..."
... which brings us to the context for the "general" question I asked in this thread:
I am trying to understand the "... This is not a supported usecase (use enterprise role from the DB, and add the enterprise role to approle). ..." feedback that I got in the context of my question in forum thread
"OPSS : addMembersToApplicationRole : The search for role failed"
at OPSS : addMembersToApplicationRole : The search for role failed
(Please post in that thread if you want to give feedback on that "use-case".)
regards
Jan

Is Kodo Datastore Identity toString URL safe?

Similar Messages

Maybe you are looking for