, requisition))
Think this has to do with implementation of anonymous keys
http://db.apache.org/ojb/docu/guides/advanced-technique.html#How+do
The new created AmortizedToolingSchedulePO object doesn't have any
mapped anonymous keys in OJB.
regards,
Armin
Manukyan, Sergey wrote:
Folks,
Just
Folks,
Just stumbled on the issue with using anonymous keys which make a
compound PK of the class.
class-descriptor class=com.lear.ojb.beans.AmortizedToolingSchedulePO
table=SVZATSDTL
!-- PK { FK (class=com.lear.ojb.beans.AmortizedToolingSchedule)
} --
field-descriptor
: Anonymous keys
Hi Vagula,
I'm sorry for the late reply - I was ill last week.
Vagula wrote:
Hi,
What are the drawbacks of using the anonymous keys?
Will there be performance bottleneck?
I have read the material in OJB site, it doesn't talk about
Hi,
What are the drawbacks of using the anonymous keys?
Will there be performance bottleneck?
I have read the material in OJB site, it doesn't talk about
drawbacks.
Regards,
Vagula
CAUTION - Disclaimer *
This e-mail contains
I'm having trouble getting a simple anonymous key example working in
my tests. My class descriptor is something like this:
class-descriptor class=domain.ChangeStatus table=gov_change_status
field-descriptor id=1 name=id column=id
jdbc-type=INTEGER nullable=false primarykey=true
Folks,
I have a question regarding anonymous keys. Without them I was
successfully using QueryByIdentity to find an object by his PK:
Query query = new QueryByIdentity(example);
retVal = broker.getObjectByQuery(query);
But when I enabled primary keys this approach stopped to work. Any
Thank you, Brian. Your reply was very helpful.
Pulat
Brian McCallister wrote:
Anonymous keys allow you to not have the FK field (or PK if you never
need serialize them) defined on the classes. By default OJB talks
directly to fields, not through property accessors (though it certainly
can work
What is the purpose of anonymous keys? Given class A and class B where
class A has a reference to class B, I removed setId() from both classes,
and setBId() and getBId() from class A. I still have private members id
in both classes, and bId in class A as well as all corresponding field
Anonymous keys allow you to not have the FK field (or PK if you never
need serialize them) defined on the classes. By default OJB talks
directly to fields, not through property accessors (though it certainly
can work through property accessors).
-Brian
On Sep 13, 2004, at 6:53 PM, Pulat
to my
earlier issues.
However, when I try to access an object with a FK value of 0 that is using
an anonymous key I get a null pointer exception.
If I don't use anonymous keys, I don't have this problem.
Do anonymous keys use primitives?
Any ideas or workarounds?
Here is the stacktrace, though
a reference like you have but ended up with the same
results that I had without such a reference.
My code looks very much like your test case, but I still get nulls on my
nested objects if I use anonymous keys and turn proxies off.
While I think you have shown that the problems must be with my code
if I use anonymous keys and turn proxies off.
While I think you have shown that the problems must be with my code
somewhere, I'm certainly baffled as to what might be wrong.
I am using PersistentFieldIntrospectorImpl and most of my properties are
private, do you suppose that would cause a problem
your problem?
regards,
Armin
Brian Latimer wrote:
At 06:09 PM 06/09/2004, Armin Waibel wrote:
Hi Brian,
sounds strange, do you use the anonymous keys in a 1:1 or 1:n
relation? Which version do you use? Have you tried latest from CVS?
Can you describe me detailed a test case to reproduce
At 06:09 PM 06/09/2004, Armin Waibel wrote:
Hi Brian,
sounds strange, do you use the anonymous keys in a 1:1 or 1:n relation?
Which version do you use? Have you tried latest from CVS?
Can you describe me detailed a test case to reproduce the problem?
I'm using rc6. I have not tried the latest
I have many persistent objects that contain references to other persistent
objects.
I am fairly certain that I have the mapping set up properly, but, the
auto-retrive doesn't seem to cascade down my objects if they use anonymous
keys. That is unless I use proxies; in which case the objects
Hmm, what I get for writing docs without stepping through code
carefully enough.
Armin has pointed out that using anonymous keys for PK's is going to
bomb if used in a clustered environment (or anywhere that persistent
objects are serialized and migrated) and he is completely correct!
Anyone
I have a situation where I have a 1-n relation between a group and its
members. The members are created independently and get assigned to a
group later (hence the null group id in member). I have the matching
reference descriptor to the Group class in Member and a collection
descriptor for the
Hi Raghaven,
don't use primitve types for FK, PK fields in your pc classes if you do
(null/0 problem).
Think you can't use anonymous access for group_id field-descriptor,
because Member ask for group_id values.
regards,
Armin
Kollivakkam R. Raghavan wrote:
I have a situation where I have a
?
Thanks,
Vincenz
-Original Message-
From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 4:45 PM
To: OJB Users List
Subject: Re: Problem with anonymous keys in 1:n back-mapping (again)
hi vincenz,
the main difference is that you use anonymous
13, 2003 8:42 PM
To: OJB Users List
Subject: Re: Problem with anonymous keys in 1:n back-mapping (again)
hi vincent,
just to make it clear the attribute 'userId' is null because
access is
anonymous and no attribute is required in your class. the attribute
'user' should contain an instance
: Problem with anonymous keys in 1:n back-mapping (again)
hi vincent,
just to make it clear the attribute 'userId' is null because
access is
anonymous and no attribute is required in your class. the attribute
'user' should contain an instance of object User.
i do have a testcase for this feature
: Re: Problem with anonymous keys in 1:n back-mapping (again)
hi vincent,
just to make it clear the attribute 'userId' is null because access is
anonymous and no attribute is required in your class. the attribute
'user' should contain an instance of object User.
i do have a testcase
20:42
Bitte antworten an OJB Users List
An: OJB Users List [EMAIL PROTECTED]
Kopie:
Thema: Re: Problem with anonymous keys in 1:n back-mapping (again)
hi vincent,
just to make it clear the attribute 'userId' is null because access is
anonymous and no attribute
An: OJB Users List [EMAIL PROTECTED]
Kopie:
Thema: Re: Problem with anonymous keys in 1:n back-mapping (again)
hi gerhard,
yup, it also works with proxy=false.
do you use the latest from repository ?
jakob
[EMAIL PROTECTED] wrote:
Hi Jakob,
It was the attribute 'user
with anonymous keys in 1:n back-mapping (again)
hi vincent,
just to make it clear the attribute 'userId' is null because
access is
anonymous and no attribute is required in your class. the attribute
'user' should contain an instance of object User.
i do have a testcase for this feature
/class-descriptor
When I now load a User object which has associated UserRoles, the user
attribute of all UserRoles is null. The problem disappears when I make
userId a normal attribute of UserRole.
Is this a known limitation of anonymous keys, is it a bug or am I doing
something wrong here
of all UserRoles is null. The problem disappears when I make
userId a normal attribute of UserRole.
Is this a known limitation of anonymous keys, is it a bug or am I doing
something wrong here?
-
To unsubscribe, e-mail: [EMAIL
attribute of all UserRoles is null. The problem disappears when I make
userId a normal attribute of UserRole.
Is this a known limitation of anonymous keys, is it a bug or am I doing
something wrong here?
-
To unsubscribe, e-mail
attribute of all UserRoles is null. The problem disappears when I make
userId a normal attribute of UserRole.
Is this a known limitation of anonymous keys, is it a bug or am I doing
something wrong here?
-
To unsubscribe, e-mail
Hah, good find, thank you!
-Brian
On Saturday, August 30, 2003, at 12:52 PM, Alexander Bibighaus wrote:
There is a bug in the example source found in the HOWTO for Anonymous
Keys
In the class Finish, the method reads as follows:
public void setWood(String nom)
{
this.wood = wood
There is a bug in the example source found in the HOWTO for Anonymous Keys
In the class Finish, the method reads as follows:
public void setWood(String nom)
{
this.wood = wood;
}
The setter has no effect.
-alexander
of all UserRoles is null. The problem disappears when I make
userId a normal attribute of UserRole.
Is this a known limitation of anonymous keys, is it a bug or am I doing
something wrong here?
Regards,
Gerhard
32 matches
Mail list logo
