Re: Binding CoreData relations

Thank you Chris. I very much appreciate the verbosity (in good sense) of your reply.

Remember that a relationship between entities defines a capability. It doesn't define concrete existence. In other words, a one-to-many relationship between Customer and Account says "one specific instances of Customer CAN BE associated with many specific instances of Account," not "one specific instance of Customer IS associated with many specific instances of Account."

I know. In this particular case it is "at least one". Thus if I add new Customer, I always need at least one Account for him. More accounts can be added later. I think you're saying that there is no place to represent this fact in the model and thus there is no way to tell the automatic mechanisms that "at least one" Account has to exist whenever new Customer is added?

Chris Hanson wrote:


Of course you can specify in the model that your Customer entity's "accounts" relationship must have a minimum count of 1 rather than 0. My point is that specifying this *constraint* in the model does *not* cause any Account to be created at runtime.

Let me say that precisely: By saying the Customer entity's "accounts" relationship has to have a minimum count of 1, you're specifying a validitly constraint on your data which will be checked at save time (or any time you wish to check it programmatically). It does *not* specify a precondition for the existence of an instance of hte Customer entity.

Yes. That is how I understood it.


Thus regardless of what you specify in your model, when you create an instance of your Customer entity, that's all you'll get: An instance of your Customer entity. If you want to create an instance of your Customer entity and its associated must-always-have-at-least-one instance of your Account entity, you'll have to write code to do so.


Yes.

Fortunately, this is actually rather simple code to write, since Core Data makes it easy to distinguish when a managed object has come into existence by being inserted into a context versus when it has come into existence by being fetched from a persistent store. Obviously you'd only have to worry about creating the default Account instance for a new Customer instance upon insertion, not fetch.

Actually I want to do it in one action (method) - on adding new Customer instance, which mean I shouldn't need to worry about insert vs. fetch. Still I seem to have some (more technical than conceptual) problems here.

I tried:

[entityArrayController insert:sender];
editedObject = [[entityArrayController selectedObjects] objectAtIndex:0];


But it fails. When I add some debug output like:

NSLog(@"%s - count %d", _cmd, [[entityArrayController arrangedObjects] count]);

before and after insert: I always receive 0 for count and thus I can't get a ref to editedObject. Of course the NSArrayController selectsInsertedObjects.

BTW. In IB one can set the control's action to be NSArrayController's add: method, which does not exist in the NSArrayController's Class Reference... Do you know whose method is that?


I also tried:

editedObject = [NSEntityDescription insertNewObjectForEntityForName:@"Account" inManagedObjectContext:entityManagedObjectContext];

With similar results: count before and after the action remains 0.

I probably do something very strange or "upside down" here...


(There's a reason I try to be very careful in my use of entity names, the term "entity," and the term "instance" when I talk about Core Data. Most of the difficulties I see people have with Core Data stem from a simple misunderstanding: They think they're creating the actual objects when they use the Xcode modeling tools, rather than creating a description of how objects are allowed to fit together.)

I see. I perceive this being a neighbour to something like database design. It never meant to me anything beyond description of the entities, their attributes and their relations. Certainly not creating any data.
.

Relevant Pages

  • Re: Binding CoreData relations
    ... In other words, a one-to-many relationship between Customer and Account says "one specific instances of Customer CAN BE associated with many specific instances of Account," not "one specific instance of Customer IS associated with many specific instances of Account." ... It does *not* specify a precondition for the existence of an instance of hte Customer entity. ... Thus regardless of what you specify in your model, when you create an instance of your Customer entity, that's all you'll get: An instance of your Customer entity. ...
    (comp.sys.mac.programmer.help)
  • Re: Administrator account disabled in SBS 2008 but password is now kn
    ... demonstrating to a very high value customer. ... passwords for both my user account and the Administrator account. ... The Server service is disabled. ... extension of a trial installation which expired due to non-use when there ...
    (microsoft.public.windows.server.sbs)
  • Re: What problems are people in the MV world trying to solve
    ... This is a combination of business and technical. ... system is centered around a customer account and the ID assigned to it so ... contact files by account ID. ... The sales analysis system only ...
    (comp.databases.pick)
  • Re: Concept-oriented programming
    ... reference {... ... concept Account in Persistent // Describes logic of account management ... concept Customer in Persistent // Describes logic of customer management ... But why you think that objects in OOP are an exception and they have to be represented only by such system level identifiers? ...
    (comp.object)
  • Re: Checking a table for an existing entry and insert into a form?
    ... I need to take a user entry from a form's text box, ... > to me to be just a flavor of customer and does not require a separate ... > this account. ... > Complaint types would be listed in a lookup table and be selected via ...
    (microsoft.public.access.gettingstarted)
Loading