I don't think I fully understand this or maybe you didn't understand why loading/saving automatically can be unexpected more than helpfull.
My problem is that I don't want to save relationships at all automatically and here's what I'm experiencing and probably other people will to:
- Getting something by ID just to update it will get too much data and I need just a single record.
- Trying to store new info provided by user will delete all related nodes because users don't send relationships which is expected way for a user to do. Having user send 100 records to update root one is just not a good way to go.
- With Kotlin @Transient doesn't work on data class constructor parameter (beta04 can't test rc1 won't even find repository beans). If I put list as member in data class it needs to be transient, I need to think of it to set it again after doing .copy() because of the transient issue and put it as var + nullable for faster performance than val + mutable list as it's easier to replace reference than to copy lists example: 1000 nodes in list and I need to replace all of their child objects by copying lists... I could also put children as var + nullable and mutable list so modifying existing list is easier than creating new one with new record or new one with removed record.
So there's many issues with other parts of technology that makes bugs with current approach and unexpected behaviours are frequent in my scenario as I'm not using it the way some might want me to.
I believe that in time many of the users will struggle with this approach as most of them won't expect storing one node will delete related nodes because they didn't set relationships back and query they used was custom to speed up things and didn't include unnecessary data for given context like relationships .
A lot of people stopped using EF (.net) and EF core because it was too unpredictable to use for same reason of storing data, deleting it etc.
Anyways it might be that Neo4j is just not a good fit for this and I should research other DBs. I took it because it looked great for storing hierarchical data which could be found fast by searching from parent down to child as structure was quite known.
EDIT: just tested it on a new project with RC1 it only removes relationships now if updating while having @Relationship field set to empty list or null. Not sure how I ended up without nodes previously it's possibly my bug. Anyways it still stays that updating where relationship node are not fetched will remove them