Re: Is it possible to override a property in an Entity subclass in CoreData?

FROM : Barry Wark
DATE : Wed Feb 20 21:33:15 2008

Ben,

Thank you for your reply!

On Feb 19, 2008 9:45 PM, Ben Trumbull <<email_removed>> wrote:
> >I would like to emulate property type overloading in CoreData. The
> >model might look something like:
> >
> >FooEntity (Abstract) {prop1:string, prop2 : UNKNOWN}
> >BarEntity (inherits FooEntity) {prop2 : int}
> >BazEntity (inherits FooEntity) {prop2 : double}
>
> Core Data doesn't support this.
>
> If you eliminate the property on FooEntity, you could do separate
> queries using -setIncludesSubentities: to fetch exactly BarEntity and
> BazEntity types and union the results.  Your managed object classes
> could all support accessors for 'prop2' (e.g. a protocol, etc) so
> dropping the property from the abstract entity wouldn't be apparent
> to the code.


This is a promissing lead, but we're hoping to let the user design a
query using NSPredicateEditor. My (limited) understanding is that it
will be hard to create multiple queries from custom
NSPredicateEditorRowTemplates--NSPredicateEditor appears designed to
create a single NSPredicate. It's (of course) quite possible I haven't
grokked NSPredicateEditor fully yet.

>
> If you didn't need to search on the property, you could use the
> transformable attribute type, and have something completely different
> in each row, let alone subentity.


Being able to perform fetches with predicates on the property is a
requirement, unfortunately.

>
> >The CoreData fetch could then translate the
> >original predicate ("prop1=='test' && prop2 == 10") into a query into
> >the appropriate column comparisons
>
> How would we know which prop2 the prop2 in the predicate refers to ?
>
> The columns have different types, and we consider strong typing a feature.
>
> Then there's the problem that integers and doubles do not compare or
> cast with perfect fidelity.
>
>      long long x = (long long)0xDEADBEEFDEADBEEFll;
>      double y = (double)x;
>      long long z = (long long)y;
>
> And z != x.  Ouch.  Now what ?
>
> How does your code know what it's going to get back and how to use it
> without loss of precision ?


Double ouch. Obviously you all have thought much more about this than
I have. I agree that strong typing is a good thing and wouldn't want
to give that up.

>
> Why do you want to conflate a column with different types anyway ?


I'm trying to emulate a key-value map. The application is a custom job
for acquiring scientific data. Each trial may have a different, and
arbitrary set of parameters (the set of parameters can be described by
a key-value map) and the value of the parameters vary in type, though
the key can (fortunately) always be a string. So in my example, prop1
corresponds to the key and prop2 to the parameter value. The
researchers need to be able to perform a query on the parameters so
that they can, e.g. find all trials with a particular set of parameter
key-value pairs. We've implemented the solution as I described in the
OP, but I'm wondering if there's a prettier way to accomplish this
goal.

barry

P.S. Thanks for the great work on CoreData!