On Jul 11, 2014, at 1:34 AM, cocoa-dev-requ...@lists.apple.com wrote: > Message: 2 > Date: Thu, 10 Jul 2014 15:00:32 -0500 > From: William Squires <wsqui...@satx.rr.com> > To: Cocoa Developers <cocoa-dev@lists.apple.com> > Subject: Converting database to Core Data > Message-ID: <cc08d0e6-7d0e-433a-94b0-e895c8960...@satx.rr.com> > Content-Type: text/plain; charset=us-ascii > > I'm trying to convert the following. I have two tables in a database, > "TransactionEntry", and "ReasonCode". A "TransactionEntry" record is just a > posting from a POS (Point-of-Sale) terminal, and has these fields (of > interest): > > Table (TransactionEntry) > ID As Int32 > PrimaryReasonCode As Int32 // both of these link to <ReasonCode>.ID > SecondaryReasonCode As Int32 > ... > > and a "ReasonCode" record is used when a certain types of transactions occur, > such as POSItemReturned, POSItemVoided, POSCommError, and a few others. > > Table (ReasonCode) > ID As Int32 > Description As Varchar(50) > ReasonCode As Int16 // just an enum > ... > > All would be good and well if the TransactionEntry table had only one > reference (.PrimaryReasonCode) to the ReasonCode table, but some transactions > (such as a voided item) require the manager to fill in both the primary and > secondary reason codes. I can create the entities, and replace the Int32 > record numbers/IDs with a relationship. > I create the relationship in entity "TransactionEntry" and set it to > "ReasonCode", leaving the inverse relationship to "none" for now. I then > create an inverse relationship in entity "ReasonCode" to refer back to > "TransactionEntry". Now I can create the inverse relationships in both > directions. 1:1 for TransactionEntry -> ReasonCode, and 1:many for ReasonCode > -> TransactionEntry. All okay so far. > Primary ReasonCode records (entities) are re-used to save memory, and the > .Description fields are pre-set to values such as, "return item", "wrong key > hit", "cc reader not working", etc... Secondary ReasonCode entities are > (usually) created on-demand from the POS terminal when the manager logs in. A > few are re-used, but mostly new entities are created. The problem now comes > when I try to create the same relationships from TransactionEntry entities to > ReasonCode entities for the secondary reason code records (entities), since > it won't let me make both inverse relationships 1:many from ReasonCode back > to TransactionEntry. > Is this a limitation of CoreData? Or is there a way around this? Can I > ignore Xcode's warnings about not having inverse relationships, and simply > set the inverse relationships from the TransactionEntry entity(ies) to the > ReasonCode Entity to "none", and simply get rid of the inverse relationships > in the ReasonCode entity? > Please help! :)
I think I can see where there is a problem. From the standpoint of your TransactionEntry record, you have two relationships to a secondary table. However, from the standpoint of the secondary table, you have two connections to the SAME object. I can imagine that this would be confusing. Suppose you tried a different approach. Let’s say you create a SINGLE many-many connection between the TransactionEntry table and the ReasonCode table. The primary and secondary reason codes then simply become items in the set of ReasonCodes. On the TransactionEntry side of things, use an OrderedSet, so you can always make the primary reason code the first item… (Theoretically, you could then have MORE than two reason codes, but you could easily prevent that if you didn’t want the feature.) Please note that if you take this approach, you will find that Core Data auto-generates a .h file for the TransactionEntry table that defines methods which don’t exist in Core Data. (This is an old, well-known problem. Google “Core Data Ordered Set”.) You can read more about this problem at http://cypressnorth.com/programming/nsinvalidargumentexception-with-nsorderedsets-using-coredata/ and find a “standard workaround” at https://github.com/CFKevinRef/KCOrderedAccessorFix. (Basically, the CocoaPod just implements the missing methods.) Cheers, Rick Aurbach Aurbach & Associates, Inc. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
