set contains(obj) returns true but remove(obj) fails.

[bytor99999]

OK. Took me sometime, but I have managed to create a "sample" project, many parts from my real app. but the key parts to replicate. So I wrote a test, and while testing to get it to match, I saw something interesting. Now I say interesting because I don't want to just go out and call myself stupid. Especially, since there is still a possibility I am not. as in not stupid.

So, what i see at this moment, is that the Collection in discussion here is not "@Fetch"d and In looking at the var values, it appears the collection is empty. So of course an empty collection will always return false for remove().

And since I am almost 2 months since I first posted this, remembering back to that day, I am pretty sure that contains() still returned true for me. That was one of the tests I did back then. Split up my line into separate lines for contains and remove and that contains did return true. But contains still should have returned false, if the collection was empty back then.

But also in my test project, even though I am sure I save an ItemSignedUp for, it isn't showing up with my User, even if I use template.fetch(user.getItemsSignedUpForEvents());

I think I am going to zip up my files and post it to the Jira ticket I opened up which is DATAGRAPH-267, so I guess you beat me to it. Maybe there is still something to this, maybe it is just me.

Thanks for all your help.

Mark

[bytor99999]

OK, I am not crazy, in my real application, the collection does get populated. So when I was testing back in May, it was populated and called remove.

So, I will have to figure out why in my test sample project it isn't getting populated even when I added @Fetch.

Mark

[bytor99999]

Basically, sometimes my collection will be empty, sometimes filled based on what happened on previous requests. When I load my User, it is through Spring Security using the User solution in the SDN Guide. So when I have later requests and I need my current User I get the User from the SecurityContext in the Session. So first load of the User when "logging in" the collection will be empty. But later the collection could have entries in it from other actions. Then go to the deleting and get contains to return true and remove to return false. So it would be very difficult to replicate that in a sample app/test.

Mark

[lassewesth]

Mark,

This is not really an answer, just some thoughts. I think you need to break down what you are trying to do into separate chunks:
- user authentication vs domain logic - do you need the same User object for both? If so, I guess you need a full, eagerly-fetched one, because that is what you will likely need for domain stuff - even though you might not need that for authentication
- do you need deep, nested equals on your entities, or is it good enough to just compare identities?
- when adding new users, attach them to the graph (call save) first, so they get an ID - before you stick them into collections and use them in domain logic

I always find simpler/ dumber/ less sophisticated/ less re-used code is easier to reason about and change

[bytor99999]

Mark,

This is not really an answer, just some thoughts. I think you need to break down what you are trying to do into separate chunks:
- user authentication vs domain logic - do you need the same User object for both? If so, I guess you need a full, eagerly-fetched one, because that is what you will likely need for domain stuff - even though you might not need that for authentication
- do you need deep, nested equals on your entities, or is it good enough to just compare identities?
- when adding new users, attach them to the graph (call save) first, so they get an ID - before you stick them into collections and use them in domain logic

I always find simpler/ dumber/ less sophisticated/ less re-used code is easier to reason about and change

"I always find simpler/ dumber/ less sophisticated/ less re-used code is easier to reason about and change"

That is always my #1 rule, philosophy, motivator. 80% of all software costs is in maintenance. Every decision I make is always based/rooted in reducing maintenance.

My User and UserDetails objects are two different objects. However, my UserDetails has a reference to a User object. Just like in the guide book. I have used this approach before and it works great for some session data without dealing directly with the HttpSession.

I agree I should be fully populating the User object that is stored inside my UserDetails.

equals methods are all defined shallow, no referenced objects should be used in equals. I only use ID, again just like in the SDN guide.

"when adding new users, attach them to the graph (call save) first, so they get an ID - before you stick them into collections and use them in domain logic"

It isn't actually User objects I am putting into the Collection. But that isn't really the point anyway.

Thanks for your insights Lasse.

Mark

[lassewesth]

For completeness:

http://spring.neo4j.org/docs#d5e807
https://jira.springsource.org/browse/DATAGRAPH-267 closed.

Regards,

Lasse