Re: Coredata Abstract Relations
Re: Coredata Abstract Relations
- Subject: Re: Coredata Abstract Relations
- From: Sammi Williams <email@hidden>
- Date: Sun, 26 Jun 2005 23:51:18 +1200
Thanks for your prompt reply.
On 26/06/2005, at 5:13 AM, mmalcolm crawford wrote:
On Jun 25, 2005, at 9:44 AM, Sammi Williams wrote:
I have a simple program for managing account information. There
are two kinds of transactions, a PersonTransaction and a
BankTransaction, both inheriting from the abstract entity
Transaction.
The Bank entity has a to-many (and inverse) relation to instances
of BankTransaction, and also a number of PersonAccounts. A person
account has a number of PersonTransactions.
My question is simply, how can the bank get every single
Transaction associated with it - this includes all its direct
BankTransactions, and also all its PersonTransactions indirectly
related to it through a PersonAccount.
Given that you already have this information, an easy way would be
to implement a custom class for the Bank entity that returns a
union of the bankTransaction relationship and the value for the key
path persons.personTransactions (or however you've named the
relationships).
Okay, this makes sense - is it not possible to do it with a fetched
property? Or is this basically a fetched property implemented with
custom logic?
Another small question is how do you define abstract properties
that should be overridden in subclasses? Can you have some kind of
abstract relationship which could either be directly coded in a
subclass, or made a fetched property in a subentity?
What are you trying to achieve?
Well, I'd like to know what the meaning of a relationship is of an
abstract class that doesn't get instantiated is - basically, is it
that all subentities being created are bound to adhere to that
relationship? i guess my problem is I don't see how an abstract
entity with a relationship works - is it just your usual kind of
relationship?
Typically in an abstract environment, a base class will define
accessors and setter methods, and leave the storage up to you - is
this the case with coredata when you add a primative attribute? IE,
if I override the setters and getters in a subentity implemented via
a subclass of NSManagedObject, will the abstract class still have a
'primative' data type allocated for that particular attribute?\
I guess my misunderstanding stems from the fact I am used to dealing
with methods which can be overridden in subclasses, whereas in
entites we typically appear to be dealing with actual primative
values. Is this the case?
Do relations for an abstract class get managed?
Is there any reason to think they would not be?
Well, since abstract classes don't get instantiated-... thats mostly
my question above.
I'm also curious - in my program, there is a third kind of
transaction type which doesn't map directly to any entity type - it
is a 'BankFee', which is charged as per the details in PersonAccount.
PersonAccount specifies the amount, and the number of days in between
bills as period.
There are a number of approaches, one being to manage a set of
objects that is some how dynamically created for every bank fee and
inserted into the users account on demand (ie, when we view the users
account, all bank fees are calculated and displayed also).
Is it possible to create transient instances of objects, or objects
that will silently disappear (ie, not be saved)? I read about a
person who had a similar problem, and i saw you mentioned that he
should just delete them - but this seems like a bit of a hack.
I think that my way of solving this problem is currently flawed, but
I'd still be interested in knowing how to solve it this way.
Thanks for your previous reply.
Sammi
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden