[
https://issues.apache.org/jira/browse/CAY-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Artyukevich updated CAY-1796:
----------------------------------
Attachment: cay1796.patch
Here we have Artist with field paintingArray (list of paintings). This field is
instance of PersistentObjectList. Last has 3 lists: objectList (that working
with), addToUnresolved and removeFromUnresolved (that should contain temporary
information).
So:
Problem №1.
objectList didn't merge information with temporary lists addedToUnresolved and
removedFromUnresolved while committing.
Such situation can occur if entity with to-many relationship, such as Artist :
1 ) has no relationship element ( has no paintings ). Then list will be null.
2 ) has PersitenceState neither NEW nor TRANSIENT ( f.e. COMMITED )
Then create paintings and connect it with Artist. All of this paintings will be
added to addedToUnresolved list. After commit they still stay there, but should
move in objectList. On the server it processed in normal way and all
information saves.
Then, any operation with list of paintings will create query. It's even not
necessary to create expression like in description. Methods size(), indexOf(),
isEmpty(), etc.. will create query on the server to fill objectList, while
paintings are in the addedToUnresolved list.
Problem №2.
F.e. Artist has list of paintings ( objectList already initialized and all
paintings are in it, f.e. after query ). All next add or remove operations will
work directly with objectList. So, lost sense of lists addedToUnresolved and
removedFromUnresolved.
Problem №3 ???
Have artist without paintings. PersistenceState of it neither NEW nor
TRANSIENT. Here we have no paintings at all. Attempt to call method
artist.getPaintingArray().size() ( isEmpty(), etc..) will create query on
server for paintings. Even if entity has COMMITED state.
Summarizing:
cay1796.patch - patch for “Problem №1”. If there was any add or remove
operations (like add/remove painting to artist), then appropriate attribute of
entity will be updated. Update means that objectList merges with
addedToUnresolved and removedFromUresolved lists. Do it throw
PersistentDescriptor. Now it has list of properties that will be updated by the
end of commit operation.
Possible solutions for other:
The real problem of point 2 and 3 in PersistentObjectList.isFault() .
And if “Problem №3” is a real problem, then common solution for both of problem
will be to change logic of PersistentObjectList.isFault() method. Otherwise
only add() and remove() methods can be changed.
As one of solution, we can leave only one list in PersistentObjectList. As I
sad in "Problem 2" part of operations already going throw "temporary" lists,
and working directly with objectList.
> ROP: All entity's to-many relationships getting faulted from database when
> using it as a parameter in qualifier expression.
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: CAY-1796
> URL: https://issues.apache.org/jira/browse/CAY-1796
> Project: Cayenne
> Issue Type: Bug
> Components: ROP
> Affects Versions: 3.1B2
> Reporter: Dzmitry Kazimirchyk
> Fix For: 3.1B3
>
> Attachments: cay1796.patch
>
>
> If entity is used as a parameter in qualifier expression all its unfaulted
> to-many relationships are faulted prior to actual query sent to server. For
> example:
> Expression exp = ExpressionFactory.matchExp(Painting.ARTIST_PROPERTY, artist);
> context.performQuery(new SelectQuery(Painting.class, exp));
> Before actual query will be sent to server all artist's to-many relationships
> will be faulted. What I see is that in the process of query serialization on
> client side PersistentObjectList.size() is invoked which triggers
> relationships' faulting from database.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
