core data subentities

  • Hi all,

    I have a basic question regarding the way subentities work in Core
    Data. My model has SuperEntity, SubOne, and SubTwo as the three
    entities, with SubOne and SubTwo having child relationships to
    SuperEntity. I was trying to test this "quick and dirty" prototype
    and found two problems.

    The first is the layout. Dragging the models to Interface Builder, I
    get an NSArrayController for the table view of SuperEntity, and
    NSObjectControllers for the two "one-object" displays of subentities.
    But they are not linked, and I'm not sure how the bindings should be
    linked.

    The second is conceptual. If I am going to be importing data
    corresponding to type SubOne, and then supplementing that with data
    from SubTwo, how exactly does that work. Is a SubOne object a
    SuperEntity with an additional attribute? The problem I especially
    envisage is if there is overlap. For instance, say they are
    dictionary words from different dictionaries.

    (SubOne data entry)
    lexeme: pen (superentity field)
    IPA: (the IPA spelling) (superentity field)
    definition: a writing implement (SubOne field)

    (SubTwo data entry)
    lexeme: pen (superentity field)
    IPA: (the IPA spelling) (superentity field)
    definition: a tool used for writing (SubTwo field)
    etymology: xxxxx (another SubTwo field)

    If I had imported the first data from a SubOne file, and then were
    importing data from a SubTwo file, I would not want to create a new
    record, but rather simply place the new information (definition and
    etymology) in the SubTwo portion. But in the real application
    (assuming I decide to use Core Data) I would in fact have many
    different types of word data, of which only a few fields (attributes
    like "lexeme") are common to all word data.

    I know the above example is not that interesting, but it is the same
    concept as what I would be doing. I haven't seen any indication of
    how to handle subentities, or for that matter, an explanation of
    whether the attributes in SuperEntity and those in the SubEntities
    are considered part of one managed object or of separate managed
    objects. So even using KVC it is unclear to me how you would be
    referencing superentity and subentity attributes.

    I've tried to read documentation but haven't seen any examples of
    this kind of structure. If anyone could give me a heads up or a super
    basic example of a similar thing, I'd really appreciate it.

    Thanks.

    Daniel
  • On Jan 11, 2008, at 12:29 PM, Daniel Child wrote:

    > The second is conceptual. If I am going to be importing data
    > corresponding to type SubOne, and then supplementing that with data
    > from SubTwo, how exactly does that work. Is a SubOne object a
    > SuperEntity with an additional attribute?
    >
    It's not clear what the difficulty is.  Entity inheritance is like
    class inheritance...
    Replace "entity" with "class" and you're pretty much there.

    mmalc
  • At 2:52 PM -0800 1/11/08, <cocoa-dev-request...> wrote:
    > If I am going to be importing data
    > corresponding to type SubOne, and then supplementing that with data
    > from SubTwo, how exactly does that work. Is a SubOne object a
    > SuperEntity with an additional attribute?

    Yes.  The relationship is analogous to a class and its ivars.

    The relationship between a managed object and its entity is "is of".
    A managed object cannot have multiple entities any more than an
    object can have multiple classes.

    "has a" relationships are denoted by attributes and relationships.

    > I haven't seen any indication of
    > how to handle subentities, or for that matter, an explanation of
    > whether the attributes in SuperEntity and those in the SubEntities
    > are considered part of one managed object or of separate managed
    > objects. So even using KVC it is unclear to me how you would be
    > referencing superentity and subentity attributes.

    It's one managed object with the union of properties.

    KVC references the attributes by name as with any other object.  You
    cannot create multiple properties of the same name within the same
    branch of an inheritance hierarchy.  In different branches of the
    hierarchy, they are simply different attributes with the same name.
    --

    -Ben
  • Please try to keep the subject line constant -- it makes threading
    easier...

    On Jan 12, 2008, at 12:32 PM, Daniel Child wrote:

    > Thank you.
    >
    > You say that its "one managed object with the union of properties."
    > But if you want to set values via KVC, then are the items referenced
    > as:
    >
    > Super.fieldOne
    > Super.fieldTwo
    > SubOne.fieldOne
    > etc.
    > for data imported from a file of SubOne records, and
    >
    > Super.fieldOne
    > Super.fieldTwo
    > SubTwo.fieldOne
    > SubTwo.fieldTwo
    > etc.
    > for data imported from a file of SubTwo records?
    >
    No.  It's not clear why you would think this.
    As stated earlier, "Entity inheritance is like class inheritance" and
    "The relationship is analogous to a class and its ivars".

    If you have:

    @interface Super : NSObject
    {
    NSString *fieldOne;
    }
    @end

    @interface Super : SubOne
    {
    NSString *fieldTwo;
    }
    @end

    then how do you access fieldOne in an instance of SubOne?

    mmalc
  • On Jan 12, 2008, at 12:32 PM, Daniel Child wrote:

    > Also, does this force me to use custom classes instead of
    > NSManagedObject?
    >
    No.

    mmalc
  • I am trying to picture how the data gets stored. Is it one file or
    three? Can I search the superentity on one of its fields and end up
    with a result set containing data from both subentities? (Presumably
    yes, but that would NOT necessarily be the case with the class-
    subclass model: depends how you store what. => I don't see that they
    are necessarily "the same.")

    And to be able to search exclusively one type of subentity, or return
    all of the subentity objects of one type, do I need a superentity
    attribute called "recordType" (or whatever is appropriate for the
    type of entity). (again my guess is "yes") i.e.

    SUPERENTITY
    fieldOne
    fieldTwo
    recordType (= {SUBONE or SUBTWO})

    SUBONE
    fieldThree
    fieldFour

    SUBTWO
    fieldFive
    fieldSix

    Or is there something about Core Data's handling of the parent-child
    relationship that automatically enables you to search for all records
    of type SUBONE without creating the recordtype field?

    All of the storage details matter to me because my sources will be of
    different types: some flat files, some XML, some whatever. The nature
    of what's inside the different subentities may be quite different,
    and they will only have a few critical fields in common.

    I've tried to read the documentation, but somehow these answers
    (which I should know before I decide whether to bother getting into
    the nitty gritty of Core Data), don't seem to be there in the summaries.

    On Jan 11, 2008, at 4:41 PM, mmalc crawford wrote:

    > On Jan 11, 2008, at 12:29 PM, Daniel Child wrote:
    >
    >> The second is conceptual. If I am going to be importing data
    >> corresponding to type SubOne, and then supplementing that with
    >> data from SubTwo, how exactly does that work. Is a SubOne object a
    >> SuperEntity with an additional attribute?
    >>
    > It's not clear what the difficulty is.  Entity inheritance is like
    > class inheritance...
    > Replace "entity" with "class" and you're pretty much there.
previous month january 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today