You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by "Kevin Menard (JIRA)" <de...@cayenne.apache.org> on 2008/03/05 16:39:16 UTC
[jira] Created: (CAY-1000) Duplicate items in list.
Duplicate items in list.
------------------------
Key: CAY-1000
URL: https://issues.apache.org/cayenne/browse/CAY-1000
Project: Cayenne
Issue Type: Bug
Components: Cayenne Core Library
Affects Versions: 1.2 [STABLE], 2.0 [STABLE], 3.0
Reporter: Kevin Menard
Assignee: Andrus Adamchik
According to the documentation on relationships (http://cayenne.apache.org/doc/relationships.html):
"Considering that Cayenne Lists are internally managed as ordered Sets, and are not allowed to contain the same object more than once, you may want to avoid modeling relationships as Sets at all, unless the object public interface requirements warrant that."
However, it is fairly trivial to show that a relationship mapped as a List can hold a duplicate. For example, the following test will fail:
public void testDuplicateAdd() {
Artist artist = (Artist) ctxt.newObject("Artist");
artist.setArtistName("a name");
assertTrue(artist.getPaintingArray().isEmpty());
// Add a single painting to the artist.
Painting painting = (Painting) ctxt.newObject("Painting");
painting.setPaintingTitle("a painting");
artist.addToPaintingArray(painting);
assertEquals(1, artist.getPaintingArray().size());
// Now add the exact same painting. Cayenne should detect the duplicate and not actually add it.
artist.addToPaintingArray(painting);
assertEquals(1, artist.getPaintingArray().size());
}
The last assertion fails because the array size will actually be 2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Mar 5, 2008, at 6:16 PM, Kevin Menard wrote:
> 1) Maintaining list semantics -- in general, I think the behavior is
> correct, I just don't think it is for Cayenne.
>
> 2) Avoiding overhead -- list membership could be a costly
> operation. This
> could be reduced by comparing by identity and/or ObjectId, however,
> which
> should be fast enough.
My thinking exactly as to why we should keep things the way they are.
Andrus
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Kevin Menard <km...@servprise.com>.
On 3/5/08 11:07 AM, "Mike Kienenberger" <mk...@gmail.com> wrote:
> What happens if you call
>
> painting.setArtist(artist);
> painting.setArtist(artist);
>
> If that doesn't give the same results as
>
> artist.addToPaintingArray(painting);
> artist.addToPaintingArray(painting);
>
> then I would say it's a bug just due to the inconsistency.
I just added another test case to test that. Indeed, the list count is just
1.
> Since we're not working with only abstract list concepts here, but are
> using lists to model relationships, my opinion would be that having
> the same object show up in the relationship list twice just because
> you identified the relationship twice is a bug.
I agree.
> For what use case would having the object show up twice be desired behavior?
The only two things I can think of are:
1) Maintaining list semantics -- in general, I think the behavior is
correct, I just don't think it is for Cayenne.
2) Avoiding overhead -- list membership could be a costly operation. This
could be reduced by comparing by identity and/or ObjectId, however, which
should be fast enough.
--
Kevin
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Robert Zeigler <ro...@puregumption.com>.
As Kevin pointed out, calling:
painting.setArtist
twice results in
artist.getPaintingArray().size() == 1
However...
painting.setArtist(artist);
artist.addToPaintingArray(painting);
Results in:
artist.getPaintingArray().size() == 2
Whether that's "inconsistent behavior" is up for discussion, but I
know I've inadvertently set both sides of the relationship before.
Anybody else? ;)
Robert
On Mar 5, 2008, at 3/510:07 AM , Mike Kienenberger wrote:
> What happens if you call
>
> painting.setArtist(artist);
> painting.setArtist(artist);
>
> If that doesn't give the same results as
>
> artist.addToPaintingArray(painting);
> artist.addToPaintingArray(painting);
>
> then I would say it's a bug just due to the inconsistency.
>
>
> Since we're not working with only abstract list concepts here, but are
> using lists to model relationships, my opinion would be that having
> the same object show up in the relationship list twice just because
> you identified the relationship twice is a bug.
>
> For what use case would having the object show up twice be desired
> behavior?
>
>
> On Wed, Mar 5, 2008 at 10:43 AM, Andrus Adamchik <andrus@objectstyle.org
> > wrote:
>>
>> On Mar 5, 2008, at 5:39 PM, Kevin Menard (JIRA) wrote:
>>
>>> However, it is fairly trivial to show that a relationship mapped as
>>> a List can hold a duplicate.
>>
>> But the question then "is this a bug"? I don't think it is.
>>
>> Andrus
>>
>>
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Mike Kienenberger <mk...@gmail.com>.
What happens if you call
painting.setArtist(artist);
painting.setArtist(artist);
If that doesn't give the same results as
artist.addToPaintingArray(painting);
artist.addToPaintingArray(painting);
then I would say it's a bug just due to the inconsistency.
Since we're not working with only abstract list concepts here, but are
using lists to model relationships, my opinion would be that having
the same object show up in the relationship list twice just because
you identified the relationship twice is a bug.
For what use case would having the object show up twice be desired behavior?
On Wed, Mar 5, 2008 at 10:43 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> On Mar 5, 2008, at 5:39 PM, Kevin Menard (JIRA) wrote:
>
> > However, it is fairly trivial to show that a relationship mapped as
> > a List can hold a duplicate.
>
> But the question then "is this a bug"? I don't think it is.
>
> Andrus
>
>
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Kevin Menard <km...@servprise.com>.
Sorry. It was some weird pseudocode. getShippingAddresses() is a standard
List returning method, so .size() should have been used.
--
Kevin
On 3/12/08 1:26 PM, "Andrus Adamchik" <an...@objectstyle.org> wrote:
>
> On Mar 12, 2008, at 6:20 PM, Kevin Menard wrote:
>
>> assertEquals(1, c.getShippingAddresses());
>
> Did you really mean this, or 'getShippingAddresses' is some cover
> method that returns int?
>
> assertEquals(1, c.getShippingAddresses().size());
>
> Andrus
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Mar 12, 2008, at 6:20 PM, Kevin Menard wrote:
> assertEquals(1, c.getShippingAddresses());
Did you really mean this, or 'getShippingAddresses' is some cover
method that returns int?
assertEquals(1, c.getShippingAddresses().size());
Andrus
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Kevin Menard <km...@servprise.com>.
Playing with this some more, I don't even think the setX() approach will
always work.
Given the following:
Customer <--------- Address
ShippingAddress extends Address
BillingAddress extends Address
The following code does not really yield expected results either:
assertEquals(0, c.getShippingAddresses());
ShippingAddress sa;
sa.setCustomer(c);
assertEquals(1, c.getShippingAddresses());
The last assertion will fail in the current context. My guess is that
Cayenne is using Address's setCustomer() rather than ShippingAddress's or
that it is having difficulty resolving the type. A new context reading the
value from the DB will return the entry in getShippingAddresses() just fine.
Likewise, using the other end of the relationship yields proper results
(i.e., calling c.addToShippingAddresses(sa)).
I guess a manual duplicate check is the only reasonable approach in that
case.
--
Kevin
On 3/5/08 12:11 PM, "Mike Kienenberger" <mk...@gmail.com> wrote:
> For what it's worth, I have always avoided this issue by only using
> the artist.setPainting(painting) method and never the
> painting.addToArtist(artist) method.
>
> Another possibility would be to have the generated template addTo*
> method do the check as Andrus points out:
>
> if(!user.getRoles().contains(role)) {
> user.addToRoles(role);
> }
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Mike Kienenberger <mk...@gmail.com>.
For what it's worth, I have always avoided this issue by only using
the artist.setPainting(painting) method and never the
painting.addToArtist(artist) method.
Another possibility would be to have the generated template addTo*
method do the check as Andrus points out:
if(!user.getRoles().contains(role)) {
user.addToRoles(role);
}
On Wed, Mar 5, 2008 at 11:52 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> On Mar 5, 2008, at 6:32 PM, Kevin Menard wrote:
>
> > I don't think anyone wants to have duplicates. That's probably the
> > largest
> > issue at hand. Telling everyone to do duplicate checks on
>
> > all tomany relationships for all entities is a bit of a bummer.
>
> Why is that a problem? The cases where duplicates could occur should
> be expected by the user. Those are well-defined cases in the
> application, not some obscure side effects of using Cayenne. E.g. I
> always do that, and don't think this is a big deal:
>
> if(!user.getRoles().contains(role)) {
> user.addToRoles(role);
> }
>
> That's no different from List.add(..) logically.
>
>
> > I have yet to map a relationship as a Set. Does the set
> > implementation used preserve iteration order?
>
> No, it is a HashSet.
>
>
> > If so, I'd advocate this being the default rather than List. Then, if
> > someone is worried about performance or random access, he can
> > explicitly
> > choose the List.
>
> -1. The performance impact will be huge.
>
>
> > Otherwise, data integrity is the default.
>
> Data integrity is not compromised. Everything that is saved to the DB
> is correct.
>
> Andrus
>
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Kevin Menard <km...@servprise.com>.
On 3/5/08 12:03 PM, "Andrus Adamchik" <an...@objectstyle.org> wrote:
>
> On Mar 5, 2008, at 6:52 PM, Andrus Adamchik wrote:
>
>>> I have yet to map a relationship as a Set. Does the set
>>> implementation used preserve iteration order?
>>
>> No, it is a HashSet.
>
> But we can probably replace it with a LinkedHashSet I guess... Then
> the iteration order will match the List expectations (even if we add
> explicit relationship ordering per recent Jira). Then users can choose
> 'Set' for relationships they are planning to modify and
> 'List' (default) for the rest.
As alluded to in another thread, I'm even thinking of an internal Set
implementation that only does object identity and object ID comparisons.
Realistically, that's what I think people care about and what maps to the
object store. These should largely be fast operations and avoid any
overhead with logical equals implementations.
Of course, the problem there is that it would break the contract of Set.
This is something that I think is endemic to ORMs anyway . . . The
difference between object equality and object equivalence. We've had to
jump through some odd hoops to support both. I'm inclined to say buck the
Set spec and only concern ourselves with DB equality.
--
Kevin
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Mar 5, 2008, at 6:52 PM, Andrus Adamchik wrote:
>> I have yet to map a relationship as a Set. Does the set
>> implementation used preserve iteration order?
>
> No, it is a HashSet.
But we can probably replace it with a LinkedHashSet I guess... Then
the iteration order will match the List expectations (even if we add
explicit relationship ordering per recent Jira). Then users can choose
'Set' for relationships they are planning to modify and
'List' (default) for the rest.
Andrus
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Mike Kienenberger <mk...@gmail.com>.
I think what makes it especially disconcerting is that two
seemingly-equivalent operations return different results.
a.set(b) called multiple times is not equivalent to b.addToA(a) called
the same number of times. As Kevin says, this means you have to have
specialized knowledge about how Cayenne works that is not intuitively
obvious.
On Wed, Mar 5, 2008 at 12:10 PM, Kevin Menard <km...@servprise.com> wrote:
> local operation. There's a disjoin here that's slightly unsettling. It's
> as if the user is just expected to know rules about how Cayenne is going to
> work with that list, rather than be able to treat it as just a list or as a
> view of the backing store. Hopefully that helps clarify my concern a bit
> more.
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Kevin Menard <km...@servprise.com>.
On 3/5/08 11:52 AM, "Andrus Adamchik" <an...@objectstyle.org> wrote:
> Why is that a problem? The cases where duplicates could occur should
> be expected by the user. Those are well-defined cases in the
> application, not some obscure side effects of using Cayenne. E.g. I
> always do that, and don't think this is a big deal:
>
> if(!user.getRoles().contains(role)) {
> user.addToRoles(role);
> }
>
> That's no different from List.add(..) logically.
Yes, but a list is supposed to be a materialization of the persisted data.
That the two can be knocked out of whack so trivially seems problematic to
me. Anything involving a count/size operation can't be taken for granted.
>
>> I have yet to map a relationship as a Set. Does the set
>> implementation used preserve iteration order?
>
> No, it is a HashSet.
This makes it a non-starter then. A LinkedHashSet would meet the
requirements, but I'm afraid those that don't care about iteration order
will be upset at the performance hit.
>> If so, I'd advocate this being the default rather than List. Then, if
>> someone is worried about performance or random access, he can
>> explicitly
>> choose the List.
>
> -1. The performance impact will be huge.
It would only be so for additions. Cayenne should be able to build up its
internal representation just as for a List and return to the user with
minimal overhead.
>> Otherwise, data integrity is the default.
>
> Data integrity is not compromised. Everything that is saved to the DB
> is correct.
True. But I'm using Cayenne so that I don't access the DB directly.
According to the list I'm getting from Cayenne, there are duplicates.
I guess I'm having a little difficulty coming to terms with this, because I
had argued the other way previously. I.e., that the list should not be a
write-through to the backing store. So, a list is really just a snapshot
copy. List removals would not cause object deletions. That was generally
vetoed. Now, I'm trying to argue that if the list is going to match the
backing store, it should always do so and the list addition shouldn't be a
local operation. There's a disjoin here that's slightly unsettling. It's
as if the user is just expected to know rules about how Cayenne is going to
work with that list, rather than be able to treat it as just a list or as a
view of the backing store. Hopefully that helps clarify my concern a bit
more.
--
Kevin
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Mar 5, 2008, at 6:32 PM, Kevin Menard wrote:
> I don't think anyone wants to have duplicates. That's probably the
> largest
> issue at hand. Telling everyone to do duplicate checks on
> all tomany relationships for all entities is a bit of a bummer.
Why is that a problem? The cases where duplicates could occur should
be expected by the user. Those are well-defined cases in the
application, not some obscure side effects of using Cayenne. E.g. I
always do that, and don't think this is a big deal:
if(!user.getRoles().contains(role)) {
user.addToRoles(role);
}
That's no different from List.add(..) logically.
> I have yet to map a relationship as a Set. Does the set
> implementation used preserve iteration order?
No, it is a HashSet.
> If so, I'd advocate this being the default rather than List. Then, if
> someone is worried about performance or random access, he can
> explicitly
> choose the List.
-1. The performance impact will be huge.
> Otherwise, data integrity is the default.
Data integrity is not compromised. Everything that is saved to the DB
is correct.
Andrus
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Kevin Menard <km...@servprise.com>.
On 3/5/08 11:19 AM, "Andrus Adamchik" <an...@objectstyle.org> wrote:
> 1. Cayenne only guarantees that *Cayenne* will return no duplicates
> for to-many. If a user explicitly wants a list to contain duplicates,
> that's his problem.
I don't think anyone wants to have duplicates. That's probably the largest
issue at hand. End user error or not, does it even really make sense? If
not, how can the framework help? Telling everyone to do duplicate checks on
all tomany relationships for all entities is a bit of a bummer.
FWIW, I had actually tried to address this globally by extending
CayenneDataObject and making my class hierarchy extend from that. I ended
up having a set of other problems, per my thread on the user list the other
day. I think they were related to the direction in which the list was being
modified, but I didn't dig into it long enough to verify. The point being
more that this could be hazardous and open us up to supporting other harder
problems to solve.
> 2. If the user wants the framework to ensure no duplicates, no matter
> what, he should use a Set.
I have yet to map a relationship as a Set. Does the set implementation used
preserve iteration order?
If so, I'd advocate this being the default rather than List. Then, if
someone is worried about performance or random access, he can explicitly
choose the List. Otherwise, data integrity is the default.
> (and I agree - let's change the docs to make it more clear)
Will do.
--
Kevin
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Mar 5, 2008, at 6:01 PM, Kevin Menard wrote:
> artist.addToPaintings(painting);
> artist.setFavorite(painting);
>
> I've seen duplicates appear such that artist.getPaintings() has two
> entries
> even though it's associated only with a single painting.
If that's the case, that would be a bug.
>> Painting painting = (Painting) ctxt.newObject("Painting");
>> painting.setPaintingTitle("a painting");
>> artist.addToPaintingArray(painting);
>> assertEquals(1, artist.getPaintingArray().size());
>> // Now add the exact same painting. Cayenne should detect
>> the duplicate and not actually add it.
>> artist.addToPaintingArray(painting);
>
The above is not a bug, but maybe we can document the behavior a
little better (and it would be insane to scan the list every time in
search of duplicates). Here is my thinking:
1. Cayenne only guarantees that *Cayenne* will return no duplicates
for to-many. If a user explicitly wants a list to contain duplicates,
that's his problem.
2. If the user wants the framework to ensure no duplicates, no matter
what, he should use a Set.
(and I agree - let's change the docs to make it more clear)
Andrus
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Kevin Menard <km...@servprise.com>.
On 3/5/08 10:43 AM, "Andrus Adamchik" <an...@objectstyle.org> wrote:
>
> On Mar 5, 2008, at 5:39 PM, Kevin Menard (JIRA) wrote:
>
>> However, it is fairly trivial to show that a relationship mapped as
>> a List can hold a duplicate.
>
> But the question then "is this a bug"? I don't think it is.
I suppose that's the million dollar question. At the very least, the
documentation is misleading. The correct behavior is another matter and is
something that has come up before on the list.
If the underlying list is supposed to represent the data rows, then I think
it is a bug. In the example provided, if I commit the context, only one
artist and one painting are going to be persisted. If in another context I
perform a query and grab the same artist, its painting list will be
different -- one element fewer.
So, there's this incongruity between the data model contents and the object
model contents. Ultimately, Cayenne does the right thing and shields a user
from invalid duplicates, but not in the object model the user is working
with.
The issue gets a little more complicated when an entity has two
relationships to another entity. I've seen duplicates appear in the
following situation.
Artist <-1--------*-- Painting
Artist --1--------1-> Painting
For instance, maybe an artist has a favorite painting, so that ID is stored
in the Artist table. Otherwise, Paintings maintain mappings to Artists.
Through a sequence of events similar to:
artist.addToPaintings(painting);
artist.setFavorite(painting);
I've seen duplicates appear such that artist.getPaintings() has two entries
even though it's associated only with a single painting.
There may be more going on there. I couldn't verify behavior with that
simple example, but I think there is something going on there.
--
Kevin
Re: [jira] Created: (CAY-1000) Duplicate items in list.
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Mar 5, 2008, at 5:39 PM, Kevin Menard (JIRA) wrote:
> However, it is fairly trivial to show that a relationship mapped as
> a List can hold a duplicate.
But the question then "is this a bug"? I don't think it is.
Andrus
[jira] Assigned: (CAY-1000) Duplicate items in list.
Posted by "Kevin Menard (JIRA)" <de...@cayenne.apache.org>.
[ https://issues.apache.org/cayenne/browse/CAY-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Menard reassigned CAY-1000:
---------------------------------
Assignee: Kevin Menard (was: Andrus Adamchik)
> Duplicate items in list.
> ------------------------
>
> Key: CAY-1000
> URL: https://issues.apache.org/cayenne/browse/CAY-1000
> Project: Cayenne
> Issue Type: Bug
> Components: Cayenne Core Library
> Affects Versions: 1.2 [STABLE], 2.0 [STABLE], 3.0
> Reporter: Kevin Menard
> Assignee: Kevin Menard
>
> According to the documentation on relationships (http://cayenne.apache.org/doc/relationships.html):
> "Considering that Cayenne Lists are internally managed as ordered Sets, and are not allowed to contain the same object more than once, you may want to avoid modeling relationships as Sets at all, unless the object public interface requirements warrant that."
> However, it is fairly trivial to show that a relationship mapped as a List can hold a duplicate. For example, the following test will fail:
> public void testDuplicateAdd() {
> Artist artist = (Artist) ctxt.newObject("Artist");
> artist.setArtistName("a name");
> assertTrue(artist.getPaintingArray().isEmpty());
> // Add a single painting to the artist.
> Painting painting = (Painting) ctxt.newObject("Painting");
> painting.setPaintingTitle("a painting");
> artist.addToPaintingArray(painting);
> assertEquals(1, artist.getPaintingArray().size());
> // Now add the exact same painting. Cayenne should detect the duplicate and not actually add it.
> artist.addToPaintingArray(painting);
> assertEquals(1, artist.getPaintingArray().size());
> }
> The last assertion fails because the array size will actually be 2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAY-1000) Duplicate items in list.
Posted by "Kevin Menard (JIRA)" <de...@cayenne.apache.org>.
[ https://issues.apache.org/cayenne/browse/CAY-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766#action_12766 ]
Kevin Menard commented on CAY-1000:
-----------------------------------
Further showing the problem:
public void testDuplicateAdd() {
Artist artist = (Artist) ctxt.newObject("Artist");
artist.setArtistName("a name");
assertTrue(artist.getPaintingArray().isEmpty());
// Add a single painting to the artist.
Painting painting = (Painting) ctxt.newObject("Painting");
painting.setPaintingTitle("a painting");
artist.addToPaintingArray(painting);
assertEquals(1, artist.getPaintingArray().size());
// Now add the exact same painting. Cayenne should detect the duplicate and not actually add it.
artist.addToPaintingArray(painting);
assertEquals(1, artist.getPaintingArray().size());
ctxt.commitChanges();
Artist doppelganger = DataObjectUtils.objectForPK(createDataContext(), Artist.class, DataObjectUtils.intPKForObject(artist));
assertEquals(1, doppelganger.getPaintingArray().size());
}
In this case, another context retrieves the same artist. That artist's painting list will be correctly of size 1, whereas the original artist is incorrectly of size 2. They both represent exactly the same data.
> Duplicate items in list.
> ------------------------
>
> Key: CAY-1000
> URL: https://issues.apache.org/cayenne/browse/CAY-1000
> Project: Cayenne
> Issue Type: Bug
> Components: Cayenne Core Library
> Affects Versions: 1.2 [STABLE], 2.0 [STABLE], 3.0
> Reporter: Kevin Menard
> Assignee: Kevin Menard
>
> According to the documentation on relationships (http://cayenne.apache.org/doc/relationships.html):
> "Considering that Cayenne Lists are internally managed as ordered Sets, and are not allowed to contain the same object more than once, you may want to avoid modeling relationships as Sets at all, unless the object public interface requirements warrant that."
> However, it is fairly trivial to show that a relationship mapped as a List can hold a duplicate. For example, the following test will fail:
> public void testDuplicateAdd() {
> Artist artist = (Artist) ctxt.newObject("Artist");
> artist.setArtistName("a name");
> assertTrue(artist.getPaintingArray().isEmpty());
> // Add a single painting to the artist.
> Painting painting = (Painting) ctxt.newObject("Painting");
> painting.setPaintingTitle("a painting");
> artist.addToPaintingArray(painting);
> assertEquals(1, artist.getPaintingArray().size());
> // Now add the exact same painting. Cayenne should detect the duplicate and not actually add it.
> artist.addToPaintingArray(painting);
> assertEquals(1, artist.getPaintingArray().size());
> }
> The last assertion fails because the array size will actually be 2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.