Antonio,
your quote from the JDO spec does not imply that the JDO objects
contained in the Collection returned by a query are unmodifiable.
You can't add and remove elements from the Collection, but you can
update the fields of the JDO objects it contains (and have JDO
update the database accordingly).
I'm using a commercial JDO implementation (kodo) with cocoon and am
very pleased with the mix. We're mostly sticking to the JDO API,
but have to use a few proprietary extensions for things not yet included
in the JDO spec (attach/detach and query aggregates). Our webapp includes
an adhoc report generator: user navigates JDO object tree, specifies
fields to extract (get*() methods to call) and relations to follow,
sorting, grouping, aggregate functions etc. Our cocoon generator adds
some predicates to implement business rules that restrict object visibility.
We can include other business logic in reports by adding extra get*()
methods
(which result in extra fields which the user can select for extraction).
Cheers,
Neil.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Behalf Of Antonio Gallardo
Sent: Monday, 23 February 2004 10:22 AM
To: [EMAIL PROTECTED]
Subject: Re: building Collection from JDO problems
Stefan Klein dijo:
> Hi Bert,
>
>> Does the problem with object identities mean that OJB is not the right
>> way to go when building forms that display editable lists? If that is
>> that case I lost quite a lot of time just trying to find an quicker way
>> to build web forms.
>> What are the limitiations of OJB exactly?
>
> thought I'd point this out to you, since it cost me a lot of time and I
> still haven't solved it in a satisfying way. AFAIK, there is a bug in the
> current OJB release rc5 with the use of javax.jdo.Query (as you use in
> your retrieve method). The objects in the collection it returns are
> actually not persistent as they should be.
Later I remeber about this issue and in fact this is not a bug!
>From the JDO 1.01 specification (page 109):
<snip>
14.6.1 Query Execution
The Query interface provides methods that execute the query based on the
parameters given. They return an UNMODIFIABLE Collection wich the user can
iterate to get results.
Executing ANY operation on the Collection that might change it throws
UnsupportedOperationException. For future extension, the signature of the
execute methods specifies that they return an Object that must be cast to
Collection by user.
</snip>
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
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]
