Core Data Inverse relationship

[spacelord]

I am working on an iOS app using Core Data.

Lets say I have 2 objects in Core Data, Object A and Object B.

A has a one-to-many relationship with B. It has an inverse property set.. so that the B objects point back to A. no problem, I understand that.

However, in the A object I want to keep track of the current B. So, I also have an Attribute called currentB.. it should indicate which object B is the current one.

How would an inverse relationship work with that? because only 1 B object can inverse back to A as the current one.

I can create the core data object model with a one way relationship, however Apple frowns on it mainly because it an cause some issues if an object is deleted and has a one way relationship. it only causes compiler warnings.. so it works one way. but it keeps bugging me that there has to be a logical way to think and name the inverse relationship that I'm trying to avoid.

Any insight from Core Data gurus?

 

[Markbnj]

How would an inverse relationship work with that? because only 1 B object can inverse back to A as the current one.

Not a Core Data guru, but anyway, I don't understand the statement above. You've got a 1::n relationship between A and B, and each B has a reference back to the A it is related to, while the A stores a reference to the "current" B. Why do you say "only 1 B object can inverse back to A as the current one?"

 

[spacelord]

To clarify, only 1 B object can inverse back to A as the current one at a time.

more examples..
lets say the A object has a property called myBs.
myBs = B1, B3, B4, B8
currentB = B4 (it could be any single B)

maybe there is a better way of storing my currentB.. in another table or structure that relates the two? I'm trying to keep it simple, yet I want a good foundation also. Core Data is a little different thinking than writing straight SQL as it tries to manage the objects for you... and maybe I'm getting hung up with some of that thinking.

 

[Schmide]

I don't know much about this but it looks like a com object model. It would seem they are complaining about circular referencing and issues with automatic garbage collecting. In a perfect world, all held references should auto delete when their reference count gets to zero; however, if objects point to each other, they will never delete.

Your best usage from the object A perspective, will be to just hold an index to the object rather than a active referenced (counted) pointer. From object B's perspective, I don't know what Core Data allows for void references, but a trick I often used to allow the arrayed objects to know their holders was to hold a void pointer and cast to a temp pointer when needed.