Are people using OJB with JBossCache? Or is the usual practice when
deploying in JBoss to ignore that cache and add OSCache or JCS? Any
preferences between the latter two?
thanks,
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
I guess I had modified JdbcAccessImpl to add some print statements.
I have solved the problem. Here's what was happening:
I had code like this: crit.addGreaterThan(contains(clob_column,
'someval'), 0), because I needed to get SQL like this:
contains(clob_column, 'someval') 0. When OJB
I am using OJB 1.0.4, Persistence Broker, Oracle 10g, Oracle Text.
I have a query which is using the Oracle Text contains() function to
search in a CLOB. It is throwing ORA-00932: inconsistent datatypes:
expected - got CLOB.
If I replace the ?'s with appropriate values and do
I am using PB in 1.0.4. I'm trying to call the Oracle Text contains()
function in my query, so I want to end up with something like this:
select ... from table1 A0, table2 A1 where ... and
contains(A1.description, 'something', 1);
The only way I can see to get there is by using addSql(), but
Ok, I guess I was living in the past - OJB used to do these as two
separate queries (get PKs, then retrieve matched objects). Didn't realize
that it was now working as you describe (good news).
I have rewritten my code to use a subquery and thus get the best of both
worlds - I can apply
I have always wondered about this, but now I am encountering a serious
performance problem which results from this policy.
When executing a Query, OJB generates two different rounds of SQL. The
first round is used just to determine the Identity of any matching
objects. These Identities are
Armin,
I'm using 1.0.4.
I am not doing a QueryByIdentity. I am doing a QueryByCriteria. So when
I do:
QueryByCriteria query = QueryFactory.newQuery(Article.class,
criteria, true);
broker.getCollectionByQuery(query);
my expectation would be that the SQL generated would be:
What I am trying to accomplish is to set the CongDist class as
read-only. I want to be able to make LocationImpl 's point at CongDists,
but I never want to update the CONG_DIST table. I have
ImplicitLocking=false and accept-locks=false, so I'm surprised to see and
UPDATE being generated for
I am seeing what looks like an old OJB bug resurfacing, and wonder if
anybody can shed some light.
I have an object with a reference to a read-only lookup table, and also a
collection of entries from another read-only lookup table. Both lookups
have accept-locks=false:
class-descriptor
When I upgraded to recent CVS 1.0.4 HEAD, I started getting constant NPEs
in equals() calls to proxies. The problem is a bug in
AbstractIndirectionHandler; here's a patch.
RCS file:
/home/cvspublic/db-ojb/src/java/org/apache/ojb/broker/core/proxy/AbstractIndirectionHandler.java,v
retrieving
I am using 1.0.4 from CVS as of yesterday. I am getting this exception,
thrown at ObjectEnvelopeTable line 602 (the comment is the infamous
should never occur). The behavior was introduced in 1.32.2.22 - I have
verified that it does not occur in 1.32.2.21.
What is happening is this: I am
Armin,
Thanks for the quick response. This patch does fix the error for me.
I'm still confused about why this code is getting called at all - it looks
like there is some implicit locking happening, even though
ImplicitLocking=false. Am I misunderstanding what's going on?
thanks,
-steve
I have a query that I can't figure out how to write. I'm using 1.0.4 and
PersistenceBroker. Here's my situation:
Project has a Collection of Activities; this is a non-decomposed m:n via
ACTIVITY_PROJECT.
Activity has attribute 'conclusionDate'.
I want to find all Projects for which every
I will be out of the office starting 07/15/2005 and will not return until
08/15/2005.
If you need help with ROAR or TAILS while I am gone, please contact Mariana
Muller (by FWS Notes email or at 970-226-9447).
Otherwise, I will respond to your email as soon as possible when I return.
thanks,
I will be out of the office starting 07/15/2005 and will not return until
08/15/2005.
I am out of the office until Monday, August 15, and I will not see your
email until I return.
If you need help with ROAR or TAILS while I am gone, please contact Mariana
Muller (by FWS Notes email or at
Is setPathOuterJoin() supposed to get a path or a single path component?
i.e., if I have an attribute path activity.staff.firstName and I want to
force an outer join to the staff table, should I call
setPathOuterJoin(staff) or setPathOuterJoin(activity.staff)? The name
of the method suggests
You need to call broker.close() when you are done with each broker. You
are actually asking for 500 simultaneously active brokers.
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
Wang Lei [EMAIL PROTECTED]
05/24/2005 09:48 AM
Please respond to
OJB Users List
Martin,
Can you elaborate on this a bit? Why does the change in location of
spy.properties solve the problem? Should deregister work on its own?
Also, would a similar consideration apply if Tomcat is using a JDBC-based
realm? I've never had any luck getting p6spy to work with Tomcat, and
Armin,
Good call. I was pretty sure it wasn't a concurrency issue, but there's a
long-forgotten daemon thread that's pre-loading all of the Counties after
the servlet is initialized. The failure occurs if this thread isn't done
loading the Counties by the time the test starts running. I'm
According to the error message, OJB is trying to set a field whose type is
DatedList (target field type) with a value which is a
RemovalAwareCollection (object value class). This is probably because
you aren't setting collection-class in the collection-descriptor. In
1.0.2, AFAIK
I am encountering a bug which doesn't quite happen reliably, but happens
about 75% of the time. The context is pretty large, so I'm going to just
describe what's going on and see if anybody has any thoughts before I try
to encapsulate it into a test case.
I'm using 1.0.3, ODMG, and the
We have encountered another bug in 1.0.3. We are using ODMG, though I
suspect this one is a PB bug. It also looks like it's related to the
problem reported last week by Bartomiej Knabel ([PB] two relations
between two classes).
Summary: I have a class Parent which has two separate m:n
I'm still having trouble with the collection stuff I asked about last
week, and now a new problem:
I use anonymous keys for essentially all of my references. With the
required-for-ODMG setting of auto-update=none, it appears that OJB never
sets the anonymous keys from the values in the
Armin,
Here's what we know so far about the anonymous key problems:
1:1 reference: Creating a new parent object and linking to an existing
child object, the FK is correctly set only if we call makePersistent() on
the parent object after the reference is established; if makePersistent()
is
So many projects, so few brain cells.
The problem with setting FK's is not in 1.0.3, it's in 1.0.0. Version
problem on my end, and now I really have upgraded in this project.
Mea maxima culpa.
Last week's collection stuff still stands, though (Armin, did you get my
test case?).
-steve
Steve
You need to implement equals() in your Pharmacy implementation class.
What's happening is that either the object in the collection or the object
that you're passing to remove() is a Proxy. The default implementation of
equals() (which is used by remove()) just uses ==. Since the objects are
Martin Armin,
Thanks for the responses. Some more info:
- The collection in question is a non-decomposed m:n.
- There actually are two collections which exhibit this problem; in one
case the child pk is an int, and in the other it's a String. The keys are
not null or 0 (the child being
Three more things:
1) I have ImplicitLocking turned off
2) My pseudocode is wrong: Actually, the parent object is created in a
different transaction. So it's like this:
tx = odmg.newTransaction();
profile = new FieldOfficeProfileImpl();
database.makePersistent(profile);
Sigh. Is it still Monday? I'll get it right eventually. Here is what is
(was) actually being done:
tx = odmg.newTransaction();
tx.begin();
profile = new FieldOfficeProfileImpl();
database.makePersistent(profile);
tx.commit();
tx = odmg.newTransaction();
Now I remember why I'm always hesitant to upgrade OJB - it seems like
there is some fundamental change to how things work. I hope things are
getting more stable, 'cause in the in-between times when I don't have to
rework, it's a great tool.
Here's where I'm stuck now. I just upgraded from
30 matches
Mail list logo
