“SwiftData inheritance relationship”

Thanks for taking the time to reply. I need to decide in viewDidLoad: what type of screen elements to create. If I'm compact, I might create a smaller toolbar for example. As I understand it, UIViewControllers inherit traitCollections - so it shouldn't matter that the view has not been added to the hierarchy yet. Not sure it explains the discrepency between FullScreen and CurrentContext either.Thanks.

You might be right there that there are more subleties in the view controller hierarchy as opposed to the view hierarchy. I haven't done a whole lot that required me to learn about that part yet. (If you present a VC using FullScreen while you are a tiny little child view controller, would you expect it to inherit the tiny little child VC's trait collection?) Not sure what the extra navigation controller is doing when it presents your VC - maybe it is using CurrentContext internally.But in any case, the trait collection can change later on at runtime, so you have to respond in those other methods anyway, right?

Not sure that I agree with you on this. Swift seems to me to preserve Liskov's substitution principle pretty well in most things (and indeed better than Objective C which allows transforming immutable properties into mutable ones).Swift's initialisation process / hierarchy is a special case, and while it does seem cumbersome, it does also have its logic. According to the language rules of Swift I don't think we can see this as a bug - Apple's documentation (https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Initialization.html) explicitly states that initialisers are only inherited when you don't implement a designated initialiser yourself (and convenience initialisers may be inherited if you implement all superclass designated initialisers). Therefore, by implementing my own designated initialiser, I may call a superclass initialiser within my initialisation method, but my class will not inherit implementations of my supercl

One of the mentioned solutions is to drop the inheritance relationships and just use a common interface for common operations. Protocols do that, and aren't unique to Swift.

Unfortunately, the relationship between the indexes and the values isn't fixed.Maybe it'll be clearer if I explain the Obj-C construct I'm converting. The old code has a large number of C-style arrays, some as ivars, some as local variables. They're indexed by integers, but in most cases the indexes are cases of a number of enums. Something like: typedef enum: NSUInteger { CompassPointNorth = 1, CompassPointSouth, CompassPointEast, CompassPointWest, CompassPointCount } CompassPoint; … MyDirection* directions [CompassPoint]; … for (i = 0; i < CompassPointCount; i++) directions [i] = [[MyDirection alloc] init… ];and so on.I can use Swift arrays and enums instead, but then I have to use '.rawValue' everywhere to index the array, and there's a big danger of using the wrong enum in any given case, since converting to an Int basically discards type checking. I can use Swift dictionaries instead, with an enum-valued key, and I get strict type checking, but then I have to use ! on every subscripting opera

First, a disclaimer: My first impression of SNOMED CT is that it doesn't map well at all to relational databases, and that's going to cause a few problems for CoreData's relational database backend. But if you implement SNOMED CT on plain SQL, you'll get to learn first hand why Core Data makes some of the implementation decisions that it does.This plan rests on the idea that Core Data scales reasonably well with having lots of entities in a model. Has anyone had experience of how well Core data scale in terms of the number of entities, or having a large hierarchy of entities with parent entities?Scale in terms of number of entities, and scaling on large number of parent entities is two different things. Having a huge number of tables is going to scale the same for any database, especially if you're using the sqlite data store. On the other hand, the large number of parent entities may cause database inflation. Historically, if you have entity types A, B, and C all ISA to type D, CoreData produces one unified

I generally make my value types conform to RawRepresentable, using types that can be coded (dictionaries and arrays of strings, numbers, booleans, dates, datas, colors, and so on), and then encode and decode the raw representation. (As a reminder, you get RawRepresentable conformance on a simple enum just by making your enum inherit from a type like Int.)

Why sad from inheriting from the correct class?

I am currenly using[room setValue:roomName.text forKey:@roomName];Sticking _address in the middle was suggestedd elsewhere.My data model has a to one relationship between addresses and rooms tables as you pointed out in an earlier post. But I am stuck on how to establish the relationship between an address and its rooms. In other words when the user enters an adress on the address form, and then proceeds to enter rooms on the room form, how do I establish that specific relationship in code. I understand it conceptually and could handle it with stratight SQL, but core data has me confused.Thanks for your reply.

Not sure this is related to what I am saying.The component model is a sound alternative to a deep inheritance hierarchy.But the specific implementation in GameplayKit prevents the sort of usage that some would regard as optimal.

You establish a relationship between two entities, an Address entity and a Room entity, by doing the following things:Get a reference to the addressGet a reference to the roomCalling [room setValue: address forKey: @name of address relationship];As the user enters an address on the address form, you're going to be performing fetches to locate matching addresses. You're probably going to want to display those addresses in a picker, table view, or collection view. Once the user has a selected address, you'll have the address reference.I assume your purpose for entering the rooms is that you're going to be creating and/or editing room instances for the user.I'd say, after working with CoreData and sqlite on different projects, there's an even chance that trying to think about how you'd do this in straight SQL is going to confuse you. It's all objects all the way down, you need to think about creating objects, setting properties, and allowing the user to select objects out of fetch results.

You got me slightly wrong over here. Let my store be local and not in a ubiquity container. Every new entry in the store will have a unique identifier. When a new entry is added to the store, the managed objects are synced between devices as records in the cloudkit key value dictionary. Then on another peer, they are inserted into the context and saved all over again in the store local to that devices. When an entry is deleted from a devices the unique identifier is synced over to the other peers and marked for deletion and then the code on the other peer finds the primary entity matching the identifier and follows the delete logic on the other peer (deleting the primary entiriy, setting its relationship end entity pointer to nil and if this was the last primairy entity object in the relaitonship end object's NSSet, delete it as well) In case of editing the primary entity i simply delete the old entry and add a new one to avoid writing a separate logic for changed relationships. Basically my