You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Brian McCallister <mc...@forthillcompany.com> on 2004/06/14 15:24:14 UTC
[ANN] OJB 1.0rc7 Released
The OJB team would like to announce the release of Apache
Object/Relational Bridge (OJB) 1.0rc7.
This release will hopefully be the final release candidate before
version 1.0. If no major problems
are discovered, OJB 1.0 will be released in one week.
DOWNLOADS
http://db.apache.org/builds/ojb/
CHANGES:
- New Apache Forrest generated web site.
- OJB.properties file has changed, don't forget to replace on update!
One new property
to set in managed environments.
- Logging settings have moved to separate OJB-logging.properties file
- Logging initialization is now decoupled form OJB initialization; this
is
described in the new reference guide for logging
- It is no longer necessary to provide an empty repository.xml file
when starting
without repository and connection descriptors
- rename/move internal package org.apache.ojb.odmg.transaction to
org.apache.ojb.broker.transaction.tm
In managed environments each (top-level) API use transaction manager
access, thus the TM related
classes are moved to the PB kernel and OJB.properties entries change.
- Base class for ODMG api access within non- or managed environments is
now
org.apache.ojb.odmg.OJB. The used org.odmg.Implementation interface
implementation
is specified in OJB.properties.
- ConnectionManager is more strict on CM.releaseConnection() method
calls. Now an
exception is thrown when CM is in a "local transaction" status when try
to release
the connection. The local tx status of ConnectionManager and
PersistenceBroker implementation
is now decoupled, useful in managed environments allows to "close the
connection" without
change the PB tx-state.
- the indirection handler (for reference proxies), and the list and set
proxy classes
can now be configured in the OJB.properties file
- new CollectionProxy interface introduced to allow the ODMG api to
make use of alternate collection
proxy implementations.
KNOWN ISSUES:
- odmg-api: It is not possible to exchange objects in 1:n references.
- odmg-api: Creation of m:n relation only works when objects created
step by step (or use PB-api
as workaround), persist a whole object graph doesn't work. On delete of
collection objects from a m:n relation
objects will be deleted from the indirection table and (unexpected
behaviour) from the referenced
table too.
- A count on ReportQueries containing groupBy does not deliver a
correct result.
- Batch handling doesn't work properly with optimistic locking.
- ReportQueries should not be used with columns referencing Classes
with extents.
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [ANN] OJB 1.0rc7 Released
Posted by Edson Carlos Ericksson Richter <ed...@mgrinformatica.com.br>.
To me, default doesn't matters... Just be really clear in DOCS that the
changes are made, because I've a near to 265000 loc here that uses
either RemovalAware and Non-RemovalAware behaviour...
Best regards,
Edson Richter
Armin Waibel wrote:
> Steve Clark wrote:
>
>>>>>>> Armin Waibel writes:
>>>>>>
>>
>>
>> Armin> ooh, seems I made a mistake in the test cases repository I
>> Armin> don't specified a "non-removeaware" collection-class. Maybe
>> Armin> I should read the docs before I start writing the next test
>> Armin> cases ;-).
>>
>> Not to beat a dead horse, but I think this is yet another very clear
>> demonstration that the default behavior is counterintuitive. It
>> really seems that it would be better for non-RemovalAwareCollection to
>> be the default, with RemovalAwareCollection available as an option for
>> those who want that behavior.
>
>
> I agree with you, but some time ago the argument for using
> RemovalAwareCollections as default collection-class was to make PB-api
> delete collection objects behaviour similar to the ODMG-api. I don't
> know when we change collection-class, but originally
> non-RemovalAwareCollection was used as default one.
>
> If most OJB user vote for an rollback to non-RAC, we can switch back
> again (hopefully the last time ;-)).
> As an alternative I will have a look in source and try to make default
> collection-class pluggable via OJB.properties file. If it will be
> possible, we can satisfy both strategies.
>
> regards,
> Armin
>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: [ANN] OJB 1.0rc7 Released
Posted by Armin Waibel <ar...@apache.org>.
Steve Clark wrote:
>>>>>>Armin Waibel writes:
>
>
> Armin> ooh, seems I made a mistake in the test cases repository I
> Armin> don't specified a "non-removeaware" collection-class. Maybe
> Armin> I should read the docs before I start writing the next test
> Armin> cases ;-).
>
> Not to beat a dead horse, but I think this is yet another very clear
> demonstration that the default behavior is counterintuitive. It
> really seems that it would be better for non-RemovalAwareCollection to
> be the default, with RemovalAwareCollection available as an option for
> those who want that behavior.
I agree with you, but some time ago the argument for using
RemovalAwareCollections as default collection-class was to make PB-api
delete collection objects behaviour similar to the ODMG-api. I don't
know when we change collection-class, but originally
non-RemovalAwareCollection was used as default one.
If most OJB user vote for an rollback to non-RAC, we can switch back
again (hopefully the last time ;-)).
As an alternative I will have a look in source and try to make default
collection-class pluggable via OJB.properties file. If it will be
possible, we can satisfy both strategies.
regards,
Armin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: [ANN] OJB 1.0rc7 Released
Posted by Steve Clark <sc...@euler.cr.usgs.gov>.
>>>>> Armin Waibel writes:
Armin> ooh, seems I made a mistake in the test cases repository I
Armin> don't specified a "non-removeaware" collection-class. Maybe
Armin> I should read the docs before I start writing the next test
Armin> cases ;-).
Not to beat a dead horse, but I think this is yet another very clear
demonstration that the default behavior is counterintuitive. It
really seems that it would be better for non-RemovalAwareCollection to
be the default, with RemovalAwareCollection available as an option for
those who want that behavior.
--
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
sclark@support.tat.fws.gov
(970)226-9291
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: [ANN] OJB 1.0rc7 Released
Posted by Armin Waibel <ar...@apache.org>.
Hi Steve,
Steve Clark wrote:
> Brian> - odmg-api: Creation of m:n relation only works when
> Brian> objects created step by step (or use PB-api as workaround),
> Brian> persist a whole object graph doesn't work. On delete of
> Brian> collection objects from a m:n relation objects will be
> Brian> deleted from the indirection table and (unexpected
> Brian> behaviour) from the referenced table too.
>
> me> Also unsure about the deletion piece: Does this mean that
> me> auto-delete="link" doesn't work with ODMG any more (it's been
> me> working ok in RC6)?
>
> Armin> hmm, at all times the top-level api need the default values
> Armin> for auto-xxx settings:
> Armin> auto-retrieve true
> Armin> auto-update false
> Armin> auto-delete false
>
> Armin> But except for auto-delete on 1:1 relation, 'false' is
> Armin> equals with 'link'.
>
> Oops. I shouldn't have brought in auto-delete. It sounds from the
> release notes like there's a new behavior where removing an object
> from an m:n relation removes the object from the db, as well. Is this
> only with RemovalAwareCollection (in which case I think it's
> expected?), or is this with all collection classes (in which case I
> think it's a new behavior and very seriously broken)?
ooh, seems I made a mistake in the test cases repository I don't
specified a "non-removeaware" collection-class. Maybe I should read the
docs before I start writing the next test cases ;-).
Will check this and remove the entry in the release notes if I have success.
Steve, thank you very much!
regards,
Armin
>
> thanks,
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: [ANN] OJB 1.0rc7 Released
Posted by Steve Clark <sc...@euler.cr.usgs.gov>.
Brian> - odmg-api: Creation of m:n relation only works when
Brian> objects created step by step (or use PB-api as workaround),
Brian> persist a whole object graph doesn't work. On delete of
Brian> collection objects from a m:n relation objects will be
Brian> deleted from the indirection table and (unexpected
Brian> behaviour) from the referenced table too.
me> Also unsure about the deletion piece: Does this mean that
me> auto-delete="link" doesn't work with ODMG any more (it's been
me> working ok in RC6)?
Armin> hmm, at all times the top-level api need the default values
Armin> for auto-xxx settings:
Armin> auto-retrieve true
Armin> auto-update false
Armin> auto-delete false
Armin> But except for auto-delete on 1:1 relation, 'false' is
Armin> equals with 'link'.
Oops. I shouldn't have brought in auto-delete. It sounds from the
release notes like there's a new behavior where removing an object
from an m:n relation removes the object from the db, as well. Is this
only with RemovalAwareCollection (in which case I think it's
expected?), or is this with all collection classes (in which case I
think it's a new behavior and very seriously broken)?
thanks,
--
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
sclark@support.tat.fws.gov
(970)226-9291
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: [ANN] OJB 1.0rc7 Released
Posted by Armin Waibel <ar...@apache.org>.
Hi Steve,
Steve Clark wrote:
> I'm wondering if the listed KNOWN ISSUES will be resolved for 1.0?
We try to list all unsolved major issues for 1.0 (we are open source,
thus there is no reason for keep quiet about known issue).
We will try to fix these problems ASAP in a 1.0x release.
> It
> sounds like not, and at least one of them worries me.
>
> Brian> - odmg-api: It is not possible to exchange objects in 1:n
> Brian> references.
>
> I'm not sure what this means. Is it a new problem?
No, sorry my bad english. Will try to explain. Say A has a 1:n relation
to B. The status of the locked referenced objects (B's) of A currently
noticed only by the size of the collection. If you now remove one B
object and add another already existing (and locked) B object the size
of the referenced collection doesn't change and the A object doesn't get
dirty and the FK in B wasn't changed.
Only in this case the bug arise.
>
> Brian> - odmg-api: Creation of m:n relation only works when
> Brian> objects created
> Brian> step by step (or use PB-api as workaround), persist a whole
> Brian> object graph doesn't work. On delete of collection objects
> Brian> from a m:n relation objects will be deleted from the
> Brian> indirection table and (unexpected behaviour) from the
> Brian> referenced table too.
>
> This sounds very big and also sounds new to me.
> I've been persisting
> object graphs in ODMG without problems.
I don't think it's new, we only don't have an test case for this problem
till now (this issue is only based on m:n relations).
> Also unsure about the
> deletion piece: Does this mean that auto-delete="link" doesn't work
> with ODMG any more (it's been working ok in RC6)?
>
hmm, at all times the top-level api need the default values for auto-xxx
settings:
auto-retrieve true
auto-update false
auto-delete false
But except for auto-delete on 1:1 relation, 'false' is equals with 'link'.
regards,
Armin
> thanks,
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: [ANN] OJB 1.0rc7 Released
Posted by Steve Clark <sc...@euler.cr.usgs.gov>.
I'm wondering if the listed KNOWN ISSUES will be resolved for 1.0? It
sounds like not, and at least one of them worries me.
Brian> - odmg-api: It is not possible to exchange objects in 1:n
Brian> references.
I'm not sure what this means. Is it a new problem?
Brian> - odmg-api: Creation of m:n relation only works when
Brian> objects created
Brian> step by step (or use PB-api as workaround), persist a whole
Brian> object graph doesn't work. On delete of collection objects
Brian> from a m:n relation objects will be deleted from the
Brian> indirection table and (unexpected behaviour) from the
Brian> referenced table too.
This sounds very big and also sounds new to me. I've been persisting
object graphs in ODMG without problems. Also unsure about the
deletion piece: Does this mean that auto-delete="link" doesn't work
with ODMG any more (it's been working ok in RC6)?
thanks,
--
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
sclark@support.tat.fws.gov
(970)226-9291
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Making OJB manage composite 1:n relationships (as opposed to
aggregate)
Posted by Joe Germuska <Jo...@Germuska.com>.
In the case where a collection is a "composite" (in the UML sense),
can OJB manage the details of that?
More specifically: I have an object with a collection. If when I
store the object, the members of the collection are different than
what is in the database, I want the records in the database which are
not in the current collection to be deleted.
If I were doing the SQL myself, I'd just do a "delete from TABLE
where fk_col = object_id" before storing the objects. I suppose as a
work around I can do that in my DAO manager before asking OJB to
store the main object. But it seems like it would be nice to have
OJB take care of it.
Did I miss it in the docs somewhere? Is there a different standard
way of dealing with this?
Thanks
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
back; I'll know I'm in the wrong place."
- Carlos Santana
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: RC7 contains JBoss TX fix? was Re: [ANN] OJB 1.0rc7 Released
Posted by Armin Waibel <ar...@apache.org>.
Hi Guido,
Guido Beutler wrote:
> Hi,
>
> does RC7 contains the JBoss transaction fix Armin build for me?
>
> The problem was to return the JDBC Connection earlyer to avoid
> "returning unknown connection" exceptions
>
yep! It also include another fix:
PersistenceBrokerFactorySyncImpl.java now always use the same PB
instance (PBF.createPer.... calls) within the same jta-transaction.
regards,
Armin
> best regards,
>
> Guido
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
RC7 contains JBoss TX fix? was Re: [ANN] OJB 1.0rc7 Released
Posted by Guido Beutler <Gu...@hrs.de>.
Hi,
does RC7 contains the JBoss transaction fix Armin build for me?
The problem was to return the JDBC Connection earlyer to avoid
"returning unknown connection" exceptions
best regards,
Guido
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: [ANN] OJB 1.0rc7 Released
Posted by Armin Waibel <ar...@apache.org>.
Hi Gary,
Gary wrote:
> Can someone please clarify exactly what property
> changed in OJB.properties as mentioned below? Thanks.
OJB.properties file new properties:
-ListProxyClass
-IndirectionHandlerClass
-SetProxyClass
-RowReaderDefaultClass
odmg specific
-ImplementationClass
The logging properties moved to a separate file.
regards,
Armin
>
>
>>- OJB.properties file has changed, don't forget to
>>replace on update!
>>One new property
>>to set in managed environments.
>
>
> --- Brian McCallister
> <mc...@forthillcompany.com> wrote:
>
>>The OJB team would like to announce the release of
>>Apache
>>Object/Relational Bridge (OJB) 1.0rc7.
>>
>>This release will hopefully be the final release
>>candidate before
>>version 1.0. If no major problems
>>are discovered, OJB 1.0 will be released in one
>>week.
>>
>>
>>DOWNLOADS
>>
>>http://db.apache.org/builds/ojb/
>>
>>
>>CHANGES:
>>
>>- New Apache Forrest generated web site.
>>
>>- OJB.properties file has changed, don't forget to
>>replace on update!
>>One new property
>>to set in managed environments.
>>
>>- Logging settings have moved to separate
>>OJB-logging.properties file
>>
>>- Logging initialization is now decoupled form OJB
>>initialization; this
>>is
>>described in the new reference guide for logging
>>
>>- It is no longer necessary to provide an empty
>>repository.xml file
>>when starting
>>without repository and connection descriptors
>>
>>- rename/move internal package
>>org.apache.ojb.odmg.transaction to
>>org.apache.ojb.broker.transaction.tm
>>In managed environments each (top-level) API use
>>transaction manager
>>access, thus the TM related
>>classes are moved to the PB kernel and
>>OJB.properties entries change.
>>
>>- Base class for ODMG api access within non- or
>>managed environments is
>>now
>>org.apache.ojb.odmg.OJB. The used
>>org.odmg.Implementation interface
>>implementation
>>is specified in OJB.properties.
>>
>>- ConnectionManager is more strict on
>>CM.releaseConnection() method
>>calls. Now an
>>exception is thrown when CM is in a "local
>>transaction" status when try
>>to release
>>the connection. The local tx status of
>>ConnectionManager and
>>PersistenceBroker implementation
>>is now decoupled, useful in managed environments
>>allows to "close the
>>connection" without
>>change the PB tx-state.
>>
>>- the indirection handler (for reference proxies),
>>and the list and set
>>proxy classes
>>can now be configured in the OJB.properties file
>>
>>- new CollectionProxy interface introduced to allow
>>the ODMG api to
>>make use of alternate collection
>>proxy implementations.
>>
>>
>>KNOWN ISSUES:
>>
>>- odmg-api: It is not possible to exchange objects
>>in 1:n references.
>>
>>- odmg-api: Creation of m:n relation only works when
>>objects created
>>step by step (or use PB-api
>>as workaround), persist a whole object graph doesn't
>>work. On delete of
>>collection objects from a m:n relation
>>objects will be deleted from the indirection table
>>and (unexpected
>>behaviour) from the referenced
>>table too.
>>
>>- A count on ReportQueries containing groupBy does
>>not deliver a
>>correct result.
>>
>>- Batch handling doesn't work properly with
>>optimistic locking.
>>
>>- ReportQueries should not be used with columns
>>referencing Classes
>>with extents.
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
>
>>To unsubscribe, e-mail:
>>ojb-user-unsubscribe@db.apache.org
>>For additional commands, e-mail:
>>ojb-user-help@db.apache.org
>>
>>
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail is new and improved - Check it out!
> http://promotions.yahoo.com/new_mail
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: [ANN] OJB 1.0rc7 Released
Posted by Gary <gl...@yahoo.com>.
Can someone please clarify exactly what property
changed in OJB.properties as mentioned below? Thanks.
> - OJB.properties file has changed, don't forget to
> replace on update!
> One new property
> to set in managed environments.
--- Brian McCallister
<mc...@forthillcompany.com> wrote:
> The OJB team would like to announce the release of
> Apache
> Object/Relational Bridge (OJB) 1.0rc7.
>
> This release will hopefully be the final release
> candidate before
> version 1.0. If no major problems
> are discovered, OJB 1.0 will be released in one
> week.
>
>
> DOWNLOADS
>
> http://db.apache.org/builds/ojb/
>
>
> CHANGES:
>
> - New Apache Forrest generated web site.
>
> - OJB.properties file has changed, don't forget to
> replace on update!
> One new property
> to set in managed environments.
>
> - Logging settings have moved to separate
> OJB-logging.properties file
>
> - Logging initialization is now decoupled form OJB
> initialization; this
> is
> described in the new reference guide for logging
>
> - It is no longer necessary to provide an empty
> repository.xml file
> when starting
> without repository and connection descriptors
>
> - rename/move internal package
> org.apache.ojb.odmg.transaction to
> org.apache.ojb.broker.transaction.tm
> In managed environments each (top-level) API use
> transaction manager
> access, thus the TM related
> classes are moved to the PB kernel and
> OJB.properties entries change.
>
> - Base class for ODMG api access within non- or
> managed environments is
> now
> org.apache.ojb.odmg.OJB. The used
> org.odmg.Implementation interface
> implementation
> is specified in OJB.properties.
>
> - ConnectionManager is more strict on
> CM.releaseConnection() method
> calls. Now an
> exception is thrown when CM is in a "local
> transaction" status when try
> to release
> the connection. The local tx status of
> ConnectionManager and
> PersistenceBroker implementation
> is now decoupled, useful in managed environments
> allows to "close the
> connection" without
> change the PB tx-state.
>
> - the indirection handler (for reference proxies),
> and the list and set
> proxy classes
> can now be configured in the OJB.properties file
>
> - new CollectionProxy interface introduced to allow
> the ODMG api to
> make use of alternate collection
> proxy implementations.
>
>
> KNOWN ISSUES:
>
> - odmg-api: It is not possible to exchange objects
> in 1:n references.
>
> - odmg-api: Creation of m:n relation only works when
> objects created
> step by step (or use PB-api
> as workaround), persist a whole object graph doesn't
> work. On delete of
> collection objects from a m:n relation
> objects will be deleted from the indirection table
> and (unexpected
> behaviour) from the referenced
> table too.
>
> - A count on ReportQueries containing groupBy does
> not deliver a
> correct result.
>
> - Batch handling doesn't work properly with
> optimistic locking.
>
> - ReportQueries should not be used with columns
> referencing Classes
> with extents.
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail:
> ojb-user-help@db.apache.org
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org