Checked into trunk.
----- Original Message -----
Sent: Monday, June 07, 2010 1:06 PM
Subject: Re: [eclipselink-dev] Re: Bug
244124 - Add Nested FetchGroup
Updated the patch.
Added a fix for setter method in case weaving for change tracking but not
for fetch groups: _persistence_propertyChange was not called.
----- Original Message -----
Sent: Monday, June 07, 2010 12:20
PM
Subject: Re: [eclipselink-dev] Re: Bug
244124 - Add Nested FetchGroup
Patch to fix non-weaving for fetch groups if not weaved for change
tracking is ready for review.
----- Original Message -----
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 -----
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 -----
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 -----
Sent: Sunday, June 06, 2010
1:33 AM
Subject: Re: [eclipselink-dev]
Re: Bug 244124 - Add Nested FetchGroup
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 -----
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 -----
Sent: Wednesday, June 02,
2010 8:16 PM
Subject: Re:
[eclipselink-dev] Re: Bug 244124 - Add Nested FetchGroup
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 -----
Sent: Tuesday, June 01,
2010 2:03 PM
Subject: Re:
[eclipselink-dev] Re: Bug 244124 - Add Nested FetchGroup
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 -----
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 -----
Sent: Tuesday, May
25, 2010 3:06 PM
Subject: Re:
[eclipselink-dev] Re: Bug 244124 - Add Nested FetchGroup
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 -----
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
-----
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
-----
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 -----
Sent: Friday,
May 14, 2010 5:58 PM
Subject: Bug
244124 - Add Nested FetchGroup
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
_______________________________________________ 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
|