|
EclipseLink 1.1.0
Hi All,
I am happy to announce that EclipseLink 1.1.0 is now complete and available for download here: www.eclipse.org/eclipselink/downloads .
There are some useful links off of the download page including a 'getting started page', and the 'release notes' for 1.1.0.
As well as bug fixes, 1.1.0 introduces feature enhancements in the following areas:
First release of DBWS
The first release of EclipseLink DBWS allows developers to easily and efficiently expose database constructs (tables, SQL, stored procedures).
Enhancements in JPA include:
- a new 1:M mapping without that doesn't require a back pointer or a separate join table to hold the associations.
- TABLE_PER_CLASS Inheritance has been added giving greater flexibility in how your relational tables associate with the classes in a hierarchy.
Enhancements in SDO include:
This release of EclipseLink includes an implementation of SDO 2.1.1 (JSR 235). This implementation conforms to the final draft and is being included with the final draft as the reference implementation.
Also I would like to say, thanks to everyone involved for all the hard work in putting this together.
Peter Krogh and Doug Clarke
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: EclipseLink 1.1.0
I am happy to announce that EclipseLink 1.1.0 is now complete and available for download here: www.eclipse.org/eclipselink/downloads .
Great! :-)
Enhancements in JPA include:
- a new 1:M mapping without that doesn't require a back pointer or a separate join table to hold the associations.
- TABLE_PER_CLASS Inheritance has been added giving greater flexibility in how your relational tables associate with the classes in a hierarchy.
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: EclipseLink 1.1.0
|
|
Re: EclipseLink 1.1.0
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Magnus,
Although, likely not the 'user' documentation you
are looking for, but the development documentation of this feature can be
found here:
Cheers,
Guy
----- Original Message -----
Sent: Thursday, March 12, 2009 5:00
PM
Subject: Re: [eclipselink-users]
EclipseLink 1.1.0
I
am happy to announce that EclipseLink 1.1.0 is now complete and available
for download here: www.eclipse.org/eclipselink/downloads .
Great! :-)
Enhancements
in JPA include:
- a new 1:M mapping without that doesn't require a
back pointer or a separate join table to hold the
associations.
- TABLE_PER_CLASS Inheritance has been added
giving greater flexibility in how your relational tables associate with the
classes in a hierarchy.
_______________________________________________
eclipselink-users
mailing
list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: EclipseLink 1.1.0
Enhancements in JPA include:
- a new 1:M mapping without that doesn't require a back pointer or a separate join table to hold the associations.
Reading this page http://wiki.eclipse.org/EclipseLink/Development/JPA2.0/uni-directional_onetomany_mapping I don't understand if HistoryPolicy is supported or not? Should these development pages be read as the way things probably will be implemented, or the way they were implemented?
Implementation sequence#3 on that page says that Historical Sessions should be supported. A bit further down it reads that "History Policy is not supported with this mapping.". Without a history policy, no historical sessions afaik? Is the support for historical sessions there, if not, will it be there in the near future, or never?
/Magnus _______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: EclipseLink 1.1.0
These pages should be considered dynamic. At this stage in the
development of this particular feature the document reflects what has
been done. Other pages for other features at different levels of
development should reflect what stage the development is at.
Historical Session support is a deferred requirement for Uni-direction
One To Many Mapping. It is mentioned in the document because it is
functionality that we would like to add. However, ss this
functionality is not a must have for this feature it has been deferred
from this release and has yet to be targeted for a future release. If
it is important to you file an enhancement request and vote for it.
Popularity of functionality helps us plan release targets.
--Gordon
Magnus Heino wrote:
Enhancements in JPA include:
- a new 1:M mapping without that doesn't require a back pointer or a
separate join table to hold the associations.
Reading this page http://wiki.eclipse.org/EclipseLink/Development/JPA2.0/uni-directional_onetomany_mapping
I don't understand if HistoryPolicy is supported or not? Should these
development pages be read as the way things probably will be
implemented, or the way they were implemented?
Implementation sequence#3 on that page says that Historical Sessions
should be supported. A bit further down it reads that "History Policy
is not supported with this mapping.". Without a history policy, no
historical sessions afaik? Is the support for historical sessions
there, if not, will it be there in the near future, or never?
/Magnus
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
 Re: EclipseLink 1.1.0
Yes, History Policy is supported by OneToOne, OneToMany,
DirectCollection, DirectToField (@Basic) and ManyToMany mappings. If
you need HistoryPolicy support you should be able to easily use a
bi-directional OneToMany mapping.
As a paying Oracle customer you should speak with your support contact
and your sales contact. I have cc'd our product manager to let him
know about your request.
As an EclipseLink community member file an enhancement request and vote
for it. Lobbing for the enhancement or even contributing the
functional will expedite its inclusion. You have already taken the
first step by contacting us.
--Gordon
Magnus Heino wrote:
Historical Session support is a deferred requirement for Uni-direction
One To Many Mapping. It is mentioned in the document because it is
functionality that we would like to add.
Is it supported for any kind of OneToOne mapping?
Reading org.eclipse.persistence.history.HistoryPolicy, I get the
impression that's the case? :-P Makes this feature not so usable imho.
However, ss this
functionality is not a must have for this feature it has been deferred
from this release and has yet to be targeted for a future release. If
it is important to you file an enhancement request and vote for it.
Popularity of functionality helps us plan release targets.
As a paying Oracle customer, are there other ways to get this
functionality in place?
Thanks,
/Magnus
--Gordon
Magnus Heino wrote:
Enhancements in JPA include:
- a new 1:M mapping without that doesn't require a back pointer or a
separate join table to hold the associations.
Reading this page http://wiki.eclipse.org/EclipseLink/Development/JPA2.0/uni-directional_onetomany_mapping
I don't understand if HistoryPolicy is supported or not? Should these
development pages be read as the way things probably will be
implemented, or the way they were implemented?
Implementation sequence#3 on that page says that Historical Sessions
should be supported. A bit further down it reads that "History Policy
is not supported with this mapping.". Without a history policy, no
historical sessions afaik? Is the support for historical sessions
there, if not, will it be there in the near future, or never?
/Magnus
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: EclipseLink 1.1.0
Could you please point me to a OneToOne and/or OneToMany example, test, or anything? I all can find are tests and references to HistoryPolicy in ManyToMany and DirectCollection.
ForeignReferenceMapping seems to have a prepareHistoricalQuery which seems to do just about nothing. CollectionMapping or OneToMany doesn't override it but ManyToManyMapping does. Or maybe I dont find the right details?
Thanks! /Magnus Heino
On Thu, Mar 19, 2009 at 3:49 PM, Gordon Yorke <gordon.yorke@...> wrote:
Yes, History Policy is supported by OneToOne, OneToMany,
DirectCollection, DirectToField (@Basic) and ManyToMany mappings. If
you need HistoryPolicy support you should be able to easily use a
bi-directional OneToMany mapping.
As a paying Oracle customer you should speak with your support contact
and your sales contact. I have cc'd our product manager to let him
know about your request.
As an EclipseLink community member file an enhancement request and vote
for it. Lobbing for the enhancement or even contributing the
functional will expedite its inclusion. You have already taken the
first step by contacting us.
--Gordon
Magnus Heino wrote:
Historical Session support is a deferred requirement for Uni-direction
One To Many Mapping. It is mentioned in the document because it is
functionality that we would like to add.
Is it supported for any kind of OneToOne mapping?
Reading org.eclipse.persistence.history.HistoryPolicy, I get the
impression that's the case? :-P Makes this feature not so usable imho.
However, ss this
functionality is not a must have for this feature it has been deferred
from this release and has yet to be targeted for a future release. If
it is important to you file an enhancement request and vote for it.
Popularity of functionality helps us plan release targets.
As a paying Oracle customer, are there other ways to get this
functionality in place?
Thanks,
/Magnus
--Gordon
Magnus Heino wrote:
Enhancements in JPA include:
- a new 1:M mapping without that doesn't require a back pointer or a
separate join table to hold the associations.
Reading this page http://wiki.eclipse.org/EclipseLink/Development/JPA2.0/uni-directional_onetomany_mapping
I don't understand if HistoryPolicy is supported or not? Should these
development pages be read as the way things probably will be
implemented, or the way they were implemented?
Implementation sequence#3 on that page says that Historical Sessions
should be supported. A bit further down it reads that "History Policy
is not supported with this mapping.". Without a history policy, no
historical sessions afaik? Is the support for historical sessions
there, if not, will it be there in the near future, or never?
/Magnus
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: EclipseLink 1.1.0
Our History support is at the Descriptor level. Mappings like
ManyToManyMapping and DirectCollectionMapping which perform direct
writes to tables (like the join table) need special History support but
the other mappings which do not manage tables themselves do not need
any direct History support.
Our tests can be found in the package
org.eclipse.persistence.testing.tests.history the tests simply update
an existing test model with history policies so that history is
recorded and our standard tests plus some additional history specific
tests are run against this model.
The EclipseLink User Guide has some information on how to configure
EclipseLink to record and read in history. (
http://wiki.eclipse.org/Configuring_a_Descriptor_(ELUG)#Configuring_a_History_Policy
). You will need to specify a DescriptorCustomizer to set the
HistoryPolicy on your Entities.
Effectively a history policy configured on an Enitity tells EclipseLink
how to record history and how to query for history. To query against
historical data you will need to use the native EclipseLink APIs and
either acquire a HistoricalSession or set an AsOfClause on your query.
See ( http://wiki.eclipse.org/Configuring_Historical_Sessions_(ELUG) )
the EclipseLink User Guide for details.
--Gordon
Magnus Heino wrote:
Could you please point me to a OneToOne and/or OneToMany example, test,
or anything? I all can find are tests and references to HistoryPolicy
in ManyToMany and DirectCollection.
ForeignReferenceMapping seems to have a prepareHistoricalQuery
which seems to do just about nothing. CollectionMapping or OneToMany
doesn't override it but ManyToManyMapping does. Or maybe I dont find
the right details?
Thanks!
/Magnus Heino
On Thu, Mar 19, 2009 at 3:49 PM, Gordon
Yorke <gordon.yorke@...>
wrote:
Yes, History Policy is
supported by OneToOne, OneToMany,
DirectCollection, DirectToField (@Basic) and ManyToMany mappings. If
you need HistoryPolicy support you should be able to easily use a
bi-directional OneToMany mapping.
As a paying Oracle customer you should speak with your support contact
and your sales contact. I have cc'd our product manager to let him
know about your request.
As an EclipseLink community member file an enhancement request and vote
for it. Lobbing for the enhancement or even contributing the
functional will expedite its inclusion. You have already taken the
first step by contacting us.
--Gordon
Magnus Heino wrote:
Historical Session support is a deferred requirement for Uni-direction
One To Many Mapping. It is mentioned in the document because it is
functionality that we would like to add.
Is it supported for any kind of OneToOne mapping?
Reading org.eclipse.persistence.history.HistoryPolicy, I get the
impression that's the case? :-P Makes this feature not so usable imho.
However, ss this
functionality is not a must have for this feature it has been deferred
from this release and has yet to be targeted for a future release. If
it is important to you file an enhancement request and vote for it.
Popularity of functionality helps us plan release targets.
As a paying Oracle customer, are there other ways to get
this
functionality in place?
Thanks,
/Magnus
--Gordon
Magnus Heino wrote:
Enhancements in JPA include:
- a new 1:M mapping without that doesn't require a back pointer or a
separate join table to hold the associations.
Reading this page http://wiki.eclipse.org/EclipseLink/Development/JPA2.0/uni-directional_onetomany_mapping
I don't understand if HistoryPolicy is supported or not? Should these
development pages be read as the way things probably will be
implemented, or the way they were implemented?
Implementation sequence#3 on that page says that Historical Sessions
should be supported. A bit further down it reads that "History Policy
is not supported with this mapping.". Without a history policy, no
historical sessions afaik? Is the support for historical sessions
there, if not, will it be there in the near future, or never?
/Magnus
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: EclipseLink 1.1.0
Hum. I do all that... I used to have triggers updating history tables, but I switch to have eclipselink maintain them now just in case...
Everything goes into my _HIST tables as expected. My query looks like this:
ReadObjectQuery query = new ReadObjectQuery(entity.getClass()); query.setSelectionCriteria(query.getExpressionBuilder().get("objectId").equal(entity.getObjectId()));
query.setAsOfClause(new AsOfClause(pastTime.getMillis())); query.dontMaintainCache(); this.entityManager.getActiveSession().executeQuery(query);
SQL executed for this is not correct:
2009-03-19 18:24:36,515 [main] DEBUG [EL Fine]: ClientSession(28329183)--Connection(24758223)--SELECT ID, OBJECTVERSION, CONSTRUCTIONYEAR, HOUSENUMBER, EXTENSIONYEAR, VERSION, OBJECTID, OBJECTSTATUS, EXEMPTADDRESSING, EASEMENTBUILDING, MAINBUILDING, NONFREEHOLDPROPERTY, VERSIONVALIDFROM, VERSIONVALIDTO FROM BUILDING_HIST WHERE (((OBJECTID = ?) AND ((ROW_START <= ?) AND ((ROW_END IS NULL) OR (ROW_END > ?)))) AND ((ROW_START <= ?) AND ((ROW_END IS NULL) OR (ROW_END > ?))))
bind => [0e8d5e65-4ae9-443c-b70a-670b27892a5c, 2009-03-19 18:24:35.0, 2009-03-19 18:24:35.0, 2009-03-19 18:24:35.0, 2009-03-19 18:24:35.0] at se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
2009-03-19 18:24:36,546 [main] DEBUG [EL Fine]: ClientSession(28329183)--Connection(24758223)--SELECT ID, VERSIONVALIDFROM, VERSIONVALIDTO, BUILDING_ID FROM REALPROPERTYREFERENCE WHERE (BUILDING_ID = ?) bind => [1] at se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
2009-03-19 18:24:36,593 [main] DEBUG [EL Fine]: ClientSession(28329183)--Connection(24758223)--SELECT ID, REALPROPERTYKEY, VERSIONVALIDFROM, VERSIONVALIDTO, LIESON_ID, AFFECTEDBY_ID, BELONGSTO_ID FROM REALPROPERTYKEY WHERE (LIESON_ID = ?)
bind => [3] at se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?) 2009-03-19 18:24:36,625 [main] DEBUG [EL Fine]: ClientSession(28329183)--Connection(24758223)--SELECT ID, OBJECTVERSION, CONSTRUCTIONYEAR, HOUSENUMBER, EXTENSIONYEAR, VERSION, OBJECTID, OBJECTSTATUS, EXEMPTADDRESSING, EASEMENTBUILDING, MAINBUILDING, NONFREEHOLDPROPERTY, VERSIONVALIDFROM, VERSIONVALIDTO FROM BUILDING WHERE (ID = ?)
bind => [1] at se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?) 2009-03-19 18:24:36,656 [main] DEBUG [EL Fine]: ClientSession(28329183)--Connection(24758223)--SELECT ID, VERSIONVALIDFROM, VERSIONVALIDTO, BUILDING_ID FROM REALPROPERTYREFERENCE WHERE (BUILDING_ID = ?)
bind => [1] at se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?) 2009-03-19 18:24:36,687 [main] DEBUG [EL Fine]: ClientSession(28329183)--Connection(24758223)--SELECT ID, REALPROPERTYKEY, VERSIONVALIDFROM, VERSIONVALIDTO, LIESON_ID, AFFECTEDBY_ID, BELONGSTO_ID FROM REALPROPERTYKEY WHERE (BELONGSTO_ID = ?)
bind => [3] at se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
It's first select goes for the right _HIST table, then all goes wrong...
Mappings are defined like this:
@PrivateOwned @OneToMany(cascade = CascadeType.ALL, mappedBy = "building") private Collection<Remark> remarks = new ArrayList<Remark>();
and on the other side:
@ManyToOne @JoinColumn(nullable = false) private Building building;
?
/Magnus Heino
2009/3/19 Gordon Yorke <gordon.yorke@...>
Our History support is at the Descriptor level. Mappings like
ManyToManyMapping and DirectCollectionMapping which perform direct
writes to tables (like the join table) need special History support but
the other mappings which do not manage tables themselves do not need
any direct History support.
Our tests can be found in the package
org.eclipse.persistence.testing.tests.history the tests simply update
an existing test model with history policies so that history is
recorded and our standard tests plus some additional history specific
tests are run against this model.
The EclipseLink User Guide has some information on how to configure
EclipseLink to record and read in history. (
http://wiki.eclipse.org/Configuring_a_Descriptor_(ELUG)#Configuring_a_History_Policy
). You will need to specify a DescriptorCustomizer to set the
HistoryPolicy on your Entities.
Effectively a history policy configured on an Enitity tells EclipseLink
how to record history and how to query for history. To query against
historical data you will need to use the native EclipseLink APIs and
either acquire a HistoricalSession or set an AsOfClause on your query.
See ( http://wiki.eclipse.org/Configuring_Historical_Sessions_(ELUG) )
the EclipseLink User Guide for details.
--Gordon
Magnus Heino wrote:
Could you please point me to a OneToOne and/or OneToMany example, test,
or anything? I all can find are tests and references to HistoryPolicy
in ManyToMany and DirectCollection.
ForeignReferenceMapping seems to have a prepareHistoricalQuery
which seems to do just about nothing. CollectionMapping or OneToMany
doesn't override it but ManyToManyMapping does. Or maybe I dont find
the right details?
Thanks!
/Magnus Heino
On Thu, Mar 19, 2009 at 3:49 PM, Gordon
Yorke <gordon.yorke@...>
wrote:
Yes, History Policy is
supported by OneToOne, OneToMany,
DirectCollection, DirectToField (@Basic) and ManyToMany mappings. If
you need HistoryPolicy support you should be able to easily use a
bi-directional OneToMany mapping.
As a paying Oracle customer you should speak with your support contact
and your sales contact. I have cc'd our product manager to let him
know about your request.
As an EclipseLink community member file an enhancement request and vote
for it. Lobbing for the enhancement or even contributing the
functional will expedite its inclusion. You have already taken the
first step by contacting us.
--Gordon
Magnus Heino wrote:
Historical Session support is a deferred requirement for Uni-direction
One To Many Mapping. It is mentioned in the document because it is
functionality that we would like to add.
Is it supported for any kind of OneToOne mapping?
Reading org.eclipse.persistence.history.HistoryPolicy, I get the
impression that's the case? :-P Makes this feature not so usable imho.
However, ss this
functionality is not a must have for this feature it has been deferred
from this release and has yet to be targeted for a future release. If
it is important to you file an enhancement request and vote for it.
Popularity of functionality helps us plan release targets.
As a paying Oracle customer, are there other ways to get
this
functionality in place?
Thanks,
/Magnus
--Gordon
Magnus Heino wrote:
Enhancements in JPA include:
- a new 1:M mapping without that doesn't require a back pointer or a
separate join table to hold the associations.
Reading this page http://wiki.eclipse.org/EclipseLink/Development/JPA2.0/uni-directional_onetomany_mapping
I don't understand if HistoryPolicy is supported or not? Should these
development pages be read as the way things probably will be
implemented, or the way they were implemented?
Implementation sequence#3 on that page says that Historical Sessions
should be supported. A bit further down it reads that "History Policy
is not supported with this mapping.". Without a history policy, no
historical sessions afaik? Is the support for historical sessions
there, if not, will it be there in the near future, or never?
/Magnus
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: EclipseLink 1.1.0
What happens if you execute the query through a HistoricalSession?
--Gordon
Magnus Heino wrote:
Hum. I do all that... I used to have triggers updating history tables,
but I switch to have eclipselink maintain them now just in case...
Everything goes into my _HIST tables as expected. My query looks
like this:
ReadObjectQuery query = new ReadObjectQuery(entity.getClass());
query.setSelectionCriteria(query.getExpressionBuilder().get("objectId").equal(entity.getObjectId()));
query.setAsOfClause(new AsOfClause(pastTime.getMillis()));
query.dontMaintainCache();
this.entityManager.getActiveSession().executeQuery(query);
SQL executed for this is not correct:
2009-03-19 18:24:36,515 [main] DEBUG [EL Fine]:
ClientSession(28329183)--Connection(24758223)--SELECT ID,
OBJECTVERSION, CONSTRUCTIONYEAR, HOUSENUMBER, EXTENSIONYEAR, VERSION,
OBJECTID, OBJECTSTATUS, EXEMPTADDRESSING, EASEMENTBUILDING,
MAINBUILDING, NONFREEHOLDPROPERTY, VERSIONVALIDFROM, VERSIONVALIDTO
FROM BUILDING_HIST WHERE (((OBJECTID = ?) AND ((ROW_START <= ?) AND
((ROW_END IS NULL) OR (ROW_END > ?)))) AND ((ROW_START <= ?) AND
((ROW_END IS NULL) OR (ROW_END > ?))))
bind
=> [0e8d5e65-4ae9-443c-b70a-670b27892a5c, 2009-03-19 18:24:35.0,
2009-03-19 18:24:35.0, 2009-03-19 18:24:35.0, 2009-03-19 18:24:35.0] at
se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
2009-03-19 18:24:36,546 [main] DEBUG [EL Fine]:
ClientSession(28329183)--Connection(24758223)--SELECT ID,
VERSIONVALIDFROM, VERSIONVALIDTO, BUILDING_ID FROM
REALPROPERTYREFERENCE WHERE (BUILDING_ID = ?)
bind
=> [1] at
se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
2009-03-19 18:24:36,593 [main] DEBUG [EL Fine]:
ClientSession(28329183)--Connection(24758223)--SELECT ID,
REALPROPERTYKEY, VERSIONVALIDFROM, VERSIONVALIDTO, LIESON_ID,
AFFECTEDBY_ID, BELONGSTO_ID FROM REALPROPERTYKEY WHERE (LIESON_ID = ?)
bind
=> [3] at
se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
2009-03-19 18:24:36,625 [main] DEBUG [EL Fine]:
ClientSession(28329183)--Connection(24758223)--SELECT ID,
OBJECTVERSION, CONSTRUCTIONYEAR, HOUSENUMBER, EXTENSIONYEAR, VERSION,
OBJECTID, OBJECTSTATUS, EXEMPTADDRESSING, EASEMENTBUILDING,
MAINBUILDING, NONFREEHOLDPROPERTY, VERSIONVALIDFROM, VERSIONVALIDTO
FROM BUILDING WHERE (ID = ?)
bind
=> [1] at
se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
2009-03-19 18:24:36,656 [main] DEBUG [EL Fine]:
ClientSession(28329183)--Connection(24758223)--SELECT ID,
VERSIONVALIDFROM, VERSIONVALIDTO, BUILDING_ID FROM
REALPROPERTYREFERENCE WHERE (BUILDING_ID = ?)
bind
=> [1] at
se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
2009-03-19 18:24:36,687 [main] DEBUG [EL Fine]:
ClientSession(28329183)--Connection(24758223)--SELECT ID,
REALPROPERTYKEY, VERSIONVALIDFROM, VERSIONVALIDTO, LIESON_ID,
AFFECTEDBY_ID, BELONGSTO_ID FROM REALPROPERTYKEY WHERE (BELONGSTO_ID =
?)
bind
=> [3] at
se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
It's first select goes for the right _HIST table, then all goes
wrong...
Mappings are defined like this:
@PrivateOwned
@OneToMany(cascade = CascadeType.ALL, mappedBy = "building")
private Collection<Remark> remarks = new
ArrayList<Remark>();
and on the other side:
@ManyToOne
@JoinColumn(nullable = false)
private Building building;
?
/Magnus Heino
2009/3/19 Gordon Yorke <gordon.yorke@...>
Our History support is at the
Descriptor level. Mappings like
ManyToManyMapping and DirectCollectionMapping which perform direct
writes to tables (like the join table) need special History support but
the other mappings which do not manage tables themselves do not need
any direct History support.
Our tests can be found in the package
org.eclipse.persistence.testing.tests.history the tests simply update
an existing test model with history policies so that history is
recorded and our standard tests plus some additional history specific
tests are run against this model.
The EclipseLink User Guide has some information on how to configure
EclipseLink to record and read in history. (
http://wiki.eclipse.org/Configuring_a_Descriptor_(ELUG)#Configuring_a_History_Policy
). You will need to specify a DescriptorCustomizer to set the
HistoryPolicy on your Entities.
Effectively a history policy configured on an Enitity tells EclipseLink
how to record history and how to query for history. To query against
historical data you will need to use the native EclipseLink APIs and
either acquire a HistoricalSession or set an AsOfClause on your query.
See ( http://wiki.eclipse.org/Configuring_Historical_Sessions_(ELUG)
)
the EclipseLink User Guide for details.
--Gordon
Magnus Heino wrote:
Could you please point me to a OneToOne and/or OneToMany example, test,
or anything? I all can find are tests and references to HistoryPolicy
in ManyToMany and DirectCollection.
ForeignReferenceMapping seems to have
a prepareHistoricalQuery
which seems to do just about nothing. CollectionMapping or OneToMany
doesn't override it but ManyToManyMapping does. Or maybe I dont find
the right details?
Thanks!
/Magnus Heino
On Thu, Mar 19, 2009 at 3:49 PM, Gordon
Yorke <gordon.yorke@...>
wrote:
Yes, History Policy is
supported by OneToOne, OneToMany,
DirectCollection, DirectToField (@Basic) and ManyToMany mappings. If
you need HistoryPolicy support you should be able to easily use a
bi-directional OneToMany mapping.
As a paying Oracle customer you should speak with your support contact
and your sales contact. I have cc'd our product manager to let him
know about your request.
As an EclipseLink community member file an enhancement request and vote
for it. Lobbing for the enhancement or even contributing the
functional will expedite its inclusion. You have already taken the
first step by contacting us.
--Gordon
Magnus Heino wrote:
Historical Session support is a deferred requirement for Uni-direction
One To Many Mapping. It is mentioned in the document because it is
functionality that we would like to add.
Is it supported for any kind of OneToOne mapping?
Reading org.eclipse.persistence.history.HistoryPolicy, I get the
impression that's the case? :-P Makes this feature not so usable imho.
However, ss this
functionality is not a must have for this feature it has been deferred
from this release and has yet to be targeted for a future release. If
it is important to you file an enhancement request and vote for it.
Popularity of functionality helps us plan release targets.
As a paying Oracle customer, are there other ways to get
this
functionality in place?
Thanks,
/Magnus
--Gordon
Magnus Heino wrote:
Enhancements in JPA include:
- a new 1:M mapping without that doesn't require a back pointer or a
separate join table to hold the associations.
Reading this page http://wiki.eclipse.org/EclipseLink/Development/JPA2.0/uni-directional_onetomany_mapping
I don't understand if HistoryPolicy is supported or not? Should these
development pages be read as the way things probably will be
implemented, or the way they were implemented?
Implementation sequence#3 on that page says that Historical Sessions
should be supported. A bit further down it reads that "History Policy
is not supported with this mapping.". Without a history policy, no
historical sessions afaik? Is the support for historical sessions
there, if not, will it be there in the near future, or never?
/Magnus
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: EclipseLink 1.1.0
Looking at the log output, things seems to work with a HistoricalSession. It's a bit harder to test though, since my current tests without the HistoricalSession use the same transaction to insert and query data before the tests rollback. Now with the HistoricalSession I need to commit data before in my test before I can access it in the HistoricalSession...
Bug? Anything more I can do? /Magnus Heino
2009/3/20 Gordon Yorke <gordon.yorke@...>
What happens if you execute the query through a HistoricalSession?
--Gordon
Magnus Heino wrote:
Hum. I do all that... I used to have triggers updating history tables,
but I switch to have eclipselink maintain them now just in case...
Everything goes into my _HIST tables as expected. My query looks
like this:
ReadObjectQuery query = new ReadObjectQuery(entity.getClass());
query.setSelectionCriteria(query.getExpressionBuilder().get("objectId").equal(entity.getObjectId()));
query.setAsOfClause(new AsOfClause(pastTime.getMillis()));
query.dontMaintainCache();
this.entityManager.getActiveSession().executeQuery(query);
SQL executed for this is not correct:
2009-03-19 18:24:36,515 [main] DEBUG [EL Fine]:
ClientSession(28329183)--Connection(24758223)--SELECT ID,
OBJECTVERSION, CONSTRUCTIONYEAR, HOUSENUMBER, EXTENSIONYEAR, VERSION,
OBJECTID, OBJECTSTATUS, EXEMPTADDRESSING, EASEMENTBUILDING,
MAINBUILDING, NONFREEHOLDPROPERTY, VERSIONVALIDFROM, VERSIONVALIDTO
FROM BUILDING_HIST WHERE (((OBJECTID = ?) AND ((ROW_START <= ?) AND
((ROW_END IS NULL) OR (ROW_END > ?)))) AND ((ROW_START <= ?) AND
((ROW_END IS NULL) OR (ROW_END > ?))))
bind
=> [0e8d5e65-4ae9-443c-b70a-670b27892a5c, 2009-03-19 18:24:35.0,
2009-03-19 18:24:35.0, 2009-03-19 18:24:35.0, 2009-03-19 18:24:35.0] at
se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
2009-03-19 18:24:36,546 [main] DEBUG [EL Fine]:
ClientSession(28329183)--Connection(24758223)--SELECT ID,
VERSIONVALIDFROM, VERSIONVALIDTO, BUILDING_ID FROM
REALPROPERTYREFERENCE WHERE (BUILDING_ID = ?)
bind
=> [1] at
se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
2009-03-19 18:24:36,593 [main] DEBUG [EL Fine]:
ClientSession(28329183)--Connection(24758223)--SELECT ID,
REALPROPERTYKEY, VERSIONVALIDFROM, VERSIONVALIDTO, LIESON_ID,
AFFECTEDBY_ID, BELONGSTO_ID FROM REALPROPERTYKEY WHERE (LIESON_ID = ?)
bind
=> [3] at
se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
2009-03-19 18:24:36,625 [main] DEBUG [EL Fine]:
ClientSession(28329183)--Connection(24758223)--SELECT ID,
OBJECTVERSION, CONSTRUCTIONYEAR, HOUSENUMBER, EXTENSIONYEAR, VERSION,
OBJECTID, OBJECTSTATUS, EXEMPTADDRESSING, EASEMENTBUILDING,
MAINBUILDING, NONFREEHOLDPROPERTY, VERSIONVALIDFROM, VERSIONVALIDTO
FROM BUILDING WHERE (ID = ?)
bind
=> [1] at
se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
2009-03-19 18:24:36,656 [main] DEBUG [EL Fine]:
ClientSession(28329183)--Connection(24758223)--SELECT ID,
VERSIONVALIDFROM, VERSIONVALIDTO, BUILDING_ID FROM
REALPROPERTYREFERENCE WHERE (BUILDING_ID = ?)
bind
=> [1] at
se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
2009-03-19 18:24:36,687 [main] DEBUG [EL Fine]:
ClientSession(28329183)--Connection(24758223)--SELECT ID,
REALPROPERTYKEY, VERSIONVALIDFROM, VERSIONVALIDTO, LIESON_ID,
AFFECTEDBY_ID, BELONGSTO_ID FROM REALPROPERTYKEY WHERE (BELONGSTO_ID =
?)
bind
=> [3] at
se.lantmateriet.eclipselink.support.SLF4JSessionLogger.?(?:?)
It's first select goes for the right _HIST table, then all goes
wrong...
Mappings are defined like this:
@PrivateOwned
@OneToMany(cascade = CascadeType.ALL, mappedBy = "building")
private Collection<Remark> remarks = new
ArrayList<Remark>();
and on the other side:
@ManyToOne
@JoinColumn(nullable = false)
private Building building;
?
/Magnus Heino
2009/3/19 Gordon Yorke <gordon.yorke@...>
Our History support is at the
Descriptor level. Mappings like
ManyToManyMapping and DirectCollectionMapping which perform direct
writes to tables (like the join table) need special History support but
the other mappings which do not manage tables themselves do not need
any direct History support.
Our tests can be found in the package
org.eclipse.persistence.testing.tests.history the tests simply update
an existing test model with history policies so that history is
recorded and our standard tests plus some additional history specific
tests are run against this model.
The EclipseLink User Guide has some information on how to configure
EclipseLink to record and read in history. (
http://wiki.eclipse.org/Configuring_a_Descriptor_(ELUG)#Configuring_a_History_Policy
). You will need to specify a DescriptorCustomizer to set the
HistoryPolicy on your Entities.
Effectively a history policy configured on an Enitity tells EclipseLink
how to record history and how to query for history. To query against
historical data you will need to use the native EclipseLink APIs and
either acquire a HistoricalSession or set an AsOfClause on your query.
See ( http://wiki.eclipse.org/Configuring_Historical_Sessions_(ELUG)
)
the EclipseLink User Guide for details.
--Gordon
Magnus Heino wrote:
Could you please point me to a OneToOne and/or OneToMany example, test,
or anything? I all can find are tests and references to HistoryPolicy
in ManyToMany and DirectCollection.
ForeignReferenceMapping seems to have
a prepareHistoricalQuery
which seems to do just about nothing. CollectionMapping or OneToMany
doesn't override it but ManyToManyMapping does. Or maybe I dont find
the right details?
Thanks!
/Magnus Heino
On Thu, Mar 19, 2009 at 3:49 PM, Gordon
Yorke <gordon.yorke@...>
wrote:
Yes, History Policy is
supported by OneToOne, OneToMany,
DirectCollection, DirectToField (@Basic) and ManyToMany mappings. If
you need HistoryPolicy support you should be able to easily use a
bi-directional OneToMany mapping.
As a paying Oracle customer you should speak with your support contact
and your sales contact. I have cc'd our product manager to let him
know about your request.
As an EclipseLink community member file an enhancement request and vote
for it. Lobbing for the enhancement or even contributing the
functional will expedite its inclusion. You have already taken the
first step by contacting us.
--Gordon
Magnus Heino wrote:
Historical Session support is a deferred requirement for Uni-direction
One To Many Mapping. It is mentioned in the document because it is
functionality that we would like to add.
Is it supported for any kind of OneToOne mapping?
Reading org.eclipse.persistence.history.HistoryPolicy, I get the
impression that's the case? :-P Makes this feature not so usable imho.
However, ss this
functionality is not a must have for this feature it has been deferred
from this release and has yet to be targeted for a future release. If
it is important to you file an enhancement request and vote for it.
Popularity of functionality helps us plan release targets.
As a paying Oracle customer, are there other ways to get
this
functionality in place?
Thanks,
/Magnus
--Gordon
Magnus Heino wrote:
Enhancements in JPA include:
- a new 1:M mapping without that doesn't require a back pointer or a
separate join table to hold the associations.
Reading this page http://wiki.eclipse.org/EclipseLink/Development/JPA2.0/uni-directional_onetomany_mapping
I don't understand if HistoryPolicy is supported or not? Should these
development pages be read as the way things probably will be
implemented, or the way they were implemented?
Implementation sequence#3 on that page says that Historical Sessions
should be supported. A bit further down it reads that "History Policy
is not supported with this mapping.". Without a history policy, no
historical sessions afaik? Is the support for historical sessions
there, if not, will it be there in the near future, or never?
/Magnus
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
EclipseLink 1.1.1
Hi All,
I am happy to announce that EclipseLink 1.1.1 is now complete and available for download here: www.eclipse.org/eclipselink/downloads .
There are some useful links off of the download page including a 'getting started page', and the 'release notes' for 1.1.1.
Peter Krogh and Doug Clarke
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
EclipseLink 1.2.0
|
