cayenne-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Artyukevich (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAY-1796) ROP: All entity's to-many relationships getting faulted from database when using it as a parameter in qualifier expression.
Date Wed, 11 Dec 2013 16:57:07 GMT

     [ 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)

Mime
View raw message