Many-to-many relationship model and core filling with Core Data attribute

I am trying to configure a simple Core Data model as follows:

Order(code, customer) Book(code, title, price) OrderBook(order_code, book_code, quantity) 

From the Core Data documentation, I see that it is not possible to match many-to-many relationships that add attributes to them. For this reason, I modeled it as follows.

enter image description here

Where:

  • From Order to OrderBook there is a one-to-many relationship with the Cascade delete rule
  • form OrderBook to Order there is a one-to-one relationship with the delete rule No action

The same is true for Book and OrderBook .

First question: Is this model valid?

Assuming the model is fine, I created the appropriate subclasses of NSManagedObject .

 Book.h/.m Order.h/.m OrderBook.h/.m 

However, I need to populate the corresponding db using the Core Data engine. To do this, I created appropriate categories, such as the following, where each category is responsible for creating itself (to support the encapsulation of objects).

 Book+Creation.h/.m Order+Creation.h/.m OrderBook+Creation.h/.m 

For example, the Book+Creation category has a class method, such as:

 + (Book *)bookWithXMLElement:(GDataXMLElement *)xmlElement inManagedObjectContext:(NSManagedObjectContext *)context; 

Now I have a problem, and I do not know how to solve it.

The model population must occur at different times. First, the table for books is populated (I create a catalog of books from an xml file). When done, I can fill out the order and order tables. To populate these tables, I use an xml file, for example:

 <orders> <order> <code>1234</code> <book>2567</book> <customer>299</customer> <quantity>4</quantity> </order> </orders> 

To create an Order managed object, I created the following method in my Order+Creation category:

 + (Order *)orderWithXMLElement:(GDataXMLElement *)xmlElement inManagedObjectContext:(NSManagedObjectContext *)context; 

After creation, the object is transferred to the OrderBook+Creation class method category to create an OrderBook managed object:

 + (OrderBook *)orderWithXMLElement:(GDataXMLElement *)xmlElement withOrder:(Order*)order inManagedObjectContext:(NSManagedObjectContext *)context { OrderBook* orderBook = [NSEntityDescription insertNewObjectForEntityForName:@"OrderBook" inManagedObjectContext:context]; orderBook.order = order; //orderBook.book = <-- how can I retrieve the book? return orderBook; } 

There is no way to create (or get) a Book object to assign it to an OrderBook object.

Second question: How to get a Book object and assign it an OrderBook ? Should I create an NSFetchRequest to select the desired Book object (the one that has the same code in the xml file, for example <book>2567</book> )? If so, is there a mechanism to improve performance for loading rquest?

Remember that the table of books is already filled.

I hope this is clear. Thanks in advance.

+7
source share
1 answer
  • Must be “nullify” and not “no action” for a “one” relationship.
  • Yes, you are right, you need a selection request.

If you have performance problems with a fetch request (it’s hard to say without knowing the number involved), you can extract the entire set of books into memory (again, maybe this is not true depending on the numbers), and then use array filtering / listing to find a specific item, but you must definitely create and profile the easiest option.

The types of deletion rules are described here , nullify is correct for the relationship between the customer and the book and orders:

cancels

Set up feedback for objects at the destination with a value of zero.

For example, if you delete a department, set all current members to zero for the department. This makes sense only if the relationship of the department for the employee is optional or if you guarantee that you will establish a new department for each employee before the next save operation.

This means that if you delete the order book, it will be deleted from the orderBooks and bookOrders sets in the Order and Book entity.

+3
source

All Articles