Checked into trunk the last patch for 2.1
----- Original Message -----
*From:* Andrei Ilitchev <mailto:andrei.ilitchev@xxxxxxxxxx>
*To:* Dev mailing list for Eclipse Persistence Services
<mailto:eclipselink-dev@xxxxxxxxxxx>
*Sent:* Monday, June 07, 2010 12:21 AM
*Subject:* Re: [eclipselink-dev] Re: Bug 244124 - Add Nested
FetchGroup
Checked into trunk Patch that fixes
java.util.ConcurrentModificationException on flush
Apparently that was caused by triggering a fetch group,
and that in turn happened because of mapping.compareForChange was
called by
DeferredChangeDetectionPolicy for a mapping outside the fetch group.
Hunted all usages of this method and changed them all to NOT be
called outside
the fetch group.
----- Original Message -----
*From:* Andrei Ilitchev <mailto:andrei.ilitchev@xxxxxxxxxx>
*To:* Dev mailing list for Eclipse Persistence Services
<mailto:eclipselink-dev@xxxxxxxxxxx>
*Sent:* Sunday, June 06, 2010 11:29 PM
*Subject:* Re: [eclipselink-dev] Re: Bug 244124 - Add Nested
FetchGroup
Checked into trunk Patch that fixes NPE in
ObjectBuilder.copyObject
----- Original Message -----
*From:* Andrei Ilitchev <mailto:andrei.ilitchev@xxxxxxxxxx>
*To:* Dev mailing list for Eclipse Persistence Services
<mailto:eclipselink-dev@xxxxxxxxxxx>
*Sent:* Sunday, June 06, 2010 7:51 PM
*Subject:* Re: [eclipselink-dev] Re: Bug 244124 - Add
Nested FetchGroup
Checked into trunk small corrections to the last patch
----- Original Message -----
*From:* Andrei Ilitchev
<mailto:andrei.ilitchev@xxxxxxxxxx>
*To:* Dev mailing list for Eclipse Persistence
Services <mailto:eclipselink-dev@xxxxxxxxxxx>
*Sent:* Sunday, June 06, 2010 1:33 AM
*Subject:* Re: [eclipselink-dev] Re: Bug 244124 - Add
Nested FetchGroup
https://bugs.eclipse.org/bugs/show_bug.cgi?id=244124
Checked into trunk assorted last minute fixes patch.
Fixed exceptions' messages;
CopyGroup now adds primary keys and version (just as
fetch group) unless
explicitly told not to do so (only applies to
CASCADE_TREE mode);
Also fixed CopyGroup so that it always switches to
CASCADE_TREE mode as soon as
(at least one) attribute is added.
Added fieldaccess.FetchGroups test suite - copy of
FetchGroups test suite, but
uses field access.
----- Original Message -----
*From:* Andrei Ilitchev
<mailto:andrei.ilitchev@xxxxxxxxxx>
*To:* Dev mailing list for Eclipse Persistence
Services <mailto:eclipselink-dev@xxxxxxxxxxx>
*Sent:* Friday, June 04, 2010 3:57 PM
*Subject:* Re: [eclipselink-dev] Re: Bug 244124 -
Add Nested FetchGroup
Checked into trunk FetchGroup validation patch -
extended.
Default and named FetchGroups validated during
FetchGroupManager post
initialization;
FetchGroup validated with all nested FetchGroups in
ObjectLevelReadQuery.prePrepare method;
Defined exceptions for invalid attributes (no
mapping, no reference mapping on
reference attribute, no reference descriptor, no
reference FetchGroupManager);
Updated serialization test.
Additions made to the original FetchGroup
validation patch:
added explicit triggering of target fetch group in
mergeInObject if it's not a superset of the source
fetch group;
addAttribute method no longer returns AttributeItem;
moved load method from LoadGroup to
AbstractSession (leaving LoagGroup empty for now);
allowed QueryHints.FETCH_GROUP and LOAD_GROUP to
accept AttributeGroup.
----- Original Message -----
*From:* Andrei Ilitchev
<mailto:andrei.ilitchev@xxxxxxxxxx>
*To:* Dev mailing list for Eclipse Persistence
Services <mailto:eclipselink-dev@xxxxxxxxxxx>
*Sent:* Wednesday, June 02, 2010 8:16 PM
*Subject:* Re: [eclipselink-dev] Re: Bug
244124 - Add Nested FetchGroup
https://bugs.eclipse.org/bugs/show_bug.cgi?id=244124
Checked into trunk CopyGroup patch
Commented out the failing tests - problems in
read merge;
Defined a new class CopyGroup derived from
AggregateGroup;
deprecated ObjectCopyingPolicy, which is now
derived fron CopyGroup;
deprecated the old copyObject method - both
versions of it;
defined a new copy method to AbstractSession
and EntityManagerImpl that takes
CopyPolicy;
copy method accepts both objects and collections;
copy method makes a copy according to
CopyPolicy -
all attributes in the CopyPolicy are copied;
none attributes outside the CopyPolicy are
copied;
the copied object assigned the corresponding
EntityFetchGroup and detached
(session == null);
In case of relational leaf attribute
("address" or "manager.phoneNumbers")
all non-reference attributes that are
included in default fetch group + pk
are copied;
copy method still not implemented in case for
entities without fetch groups (no
fetch group manager);
By default CopyGroup
like the old ObjectCopyingPolicy uses
CASCADE_PRIVATE_PARTS cascading;
unlike it doesn't nullify copy's pk;
As soon as an attribute is added to CopyPolicy
its cascading is changed to the
new CASCADE_TREE option that is a new
functionality.
----- Original Message -----
*From:* Andrei Ilitchev
<mailto:andrei.ilitchev@xxxxxxxxxx>
*To:* Dev mailing list for Eclipse
Persistence Services
<mailto:eclipselink-dev@xxxxxxxxxxx>
*Sent:* Tuesday, June 01, 2010 2:03 PM
*Subject:* Re: [eclipselink-dev] Re: Bug
244124 - Add Nested FetchGroup
https://bugs.eclipse.org/bugs/show_bug.cgi?id=244124
Checked into trunk:
Correction patch after James' review.
James' comments:
- addPartialAttribute, did you also
deprecate the one that takes an Expression?
- ObjectLevelReadQuery,
addSelectionFieldsForJoinedExpression,
code is odd,
cast to Vector<DatabaseField> but then
casts to Object and allows Expression?
- getFetchGroupSelectionFields, in general
try to avoid using Vector (List).
- shouldReadMapping, short circuit was
removed?
Some more comments from refreshing my view.
- FetchGroupManager, has a bunch of public
methods that should be marked
internal
- Should have a test for embeddable
attributes, we should probably throw some
kind of error if we don't support this,
also aggregate collections.
- ForeignReferenceMapping,
batchValueFromRow, the setting of the
fetch group
should be in the prepare of the nested
batch query, not cloning it and
repreparing it.
- FetchGroup, set/shouldLoad should have a
user comment explaining what is does
- LoadGroup, should avoid using
DescriptorIterator as performance issue
and not
polymorphic, should dispatch to
ObjectBuilder/mappings
- ObjectLevelReadQuery, setting of fetch
group should be in mapping, not
cloning and repreparing query in query
- ClassWeaver, does not look like fetch
groups are weaved if change tracking is
not weaved?
- MethodWeaver, same thing
- QuerySQLTracker uses tabs, also the
class already exists in the testing
framework package, so no need to define
another
The patch corrects most of the problems
mentioned in these comments.
----- Original Message -----
*From:* Andrei Ilitchev
<mailto:andrei.ilitchev@xxxxxxxxxx>
*To:* Dev mailing list for Eclipse
Persistence Services
<mailto:eclipselink-dev@xxxxxxxxxxx>
*Sent:* Tuesday, May 25, 2010 5:24 PM
*Subject:* Re: [eclipselink-dev] Re:
Bug 244124 - Add Nested FetchGroup
Bug 244124 - Add Nested FetchGroup
Checked into trunk two independent
patches for fetch groups: fetch joins
and weaving.
Fetch join patch - take 2.
A new version of patch that adds
support for fetch joins used together with
nested fetch groups.
In case joined attribute is outside of
the fetch group a WARNING is logged.
The query still works but very
inefficiently: the fetch group is
triggered and
the whole object is read in.
The only possibility here would be to
throw an exception instead - throwing
away joined attribute (don't know how
hard that would be to do) doesn't seem
right - both fetch group and fetch
joins specified directly on the query.
Weaving patch
Fixes some weaving problems introduced
in Main patch (see bug 314340).
This patch fixes only part of that
bug: static weaving tests pass, but
beanvalidation tests still fail.
----- Original Message -----
*From:* Andrei Ilitchev
<mailto:andrei.ilitchev@xxxxxxxxxx>
*To:* Dev mailing list for Eclipse
Persistence Services
<mailto:eclipselink-dev@xxxxxxxxxxx>
*Sent:* Tuesday, May 25, 2010 3:06 PM
*Subject:* Re: [eclipselink-dev]
Re: Bug 244124 - Add Nested
FetchGroup
https://bugs.eclipse.org/bugs/show_bug.cgi?id=244124
Fetch join patch - take 2.
A new version of patch that adds
support for fetch joins used
together with
nested fetch groups.
In case joined attribute is
outside of the fetch group a
WARNING is logged.
The query still works but very
inefficiently: the fetch group is
triggered and
the whole object is read in.
The only possibility here would be
to throw an exception instead -
throwing
away joined attribute (don't know
how hard that would be to do)
doesn't seem
right - both fetch group and fetch
joins specified directly on the query.
----- Original Message -----
*From:* Andrei Ilitchev
<mailto:andrei.ilitchev@xxxxxxxxxx>
*To:* Dev mailing list for
Eclipse Persistence Services
<mailto:eclipselink-dev@xxxxxxxxxxx>
*Sent:* Wednesday, May 19,
2010 4:33 PM
*Subject:* Re:
[eclipselink-dev] Re: Bug
244124 - Add Nested FetchGroup
Addition to prev. patch
Added load method to
AbstractSession, too.
Checked into trunk.
----- Original Message -----
*From:* Andrei Ilitchev
<mailto:andrei.ilitchev@xxxxxxxxxx>
*To:* Dev mailing list for
Eclipse Persistence
Services
<mailto:eclipselink-dev@xxxxxxxxxxx>
*Sent:* Wednesday, May 19,
2010 3:35 PM
*Subject:*
[eclipselink-dev] Re: Bug
244124 - Add Nested
FetchGroup
Checked into trunk Main
patch - take 3.
There are some things not
done yet:
1) merging in cache still
uses "one-storey" union;
2) fetch joins
All the fetch groups
assigned to objects now
are of type EntityFetchGroup.
It's a flat (not nested)
fetch group that only
reflects the state of its
owner
object.
A single EntityFetchGroup
may be shared by many
objects, and it is immutable.
An EntityFetchGroup
usually not created
directly but rather looked
up on the
FetchGroupmanager (keyed
by set of its attributes).
When a value is set into
not fetched attribute in
serialized object (the one
that doesn't have a
session) then a new
EntityFetchGroup created
to reflect the
new object's fetch state.
Deprecated partial attributes
Added LOAD_GROUP_ATTRIBUTE
QueryHint.
Added "load" method to
JpaEntityManager.
----- Original Message
-----
*From:* Andrei
Ilitchev
<mailto:andrei.ilitchev@xxxxxxxxxx>
*To:* Dev mailing list
for Eclipse
Persistence Services
<mailto:eclipselink-dev@xxxxxxxxxxx>
*Sent:* Friday, May
14, 2010 8:51 PM
*Subject:* Re: Bug
244124 - Add Nested
FetchGroup
Rolledback my last fix
for Bug 244124 - Add
Nested FetchGroup.
It caused cb test
failures in moxy and dbws.
Back to the prev. rev.7240
Will investigate on
Monday.
----- Original
Message -----
*From:* Andrei
Ilitchev
<mailto:andrei.ilitchev@xxxxxxxxxx>
*To:* Dev mailing
list for Eclipse
Persistence
Services
<mailto:eclipselink-dev@xxxxxxxxxxx>
*Sent:* Friday,
May 14, 2010 5:58 PM
*Subject:* Bug
244124 - Add
Nested FetchGroup
https://bugs.eclipse.org/bugs/show_bug.cgi?id=244124
Checked into trunk.
Main patch.
The patch provides
basic nested fetch
group functionality.
FetchGroup got a
new shouldLoad
flag - it
indicates whether
its attributes
should be loaded.
Also there is a
new class
LoadGroup, which
allows to manage
loading of
individual
relational attributes.
There is still
work to be done in
the area of
merging with cache
and fetch
joins.
A new test package
org.eclipse.persistence.testing.tests.jpa.fetchgroups
was
added.
See simple
examples of
different loading
arrangements in
findMinEmployee tests
in
NestedDefaultFetchGroupTests.
A simple merge was
tested and works:
serialize object
with a fetch group
applied to it;
update serialized
object (even
attribute outside
the fetch group);
serialize it back
to the server;
merge.
See a simple
example in
SimpleSerializeFetchGroupTests.simpleSerializeAndMerge.
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
