On Aug 6, 2008, at 12:31 PM, Sandro Noel wrote:
I have entities like this.
TransactionTypes
Atributes : Name:String
Relationships: Transaction
Transactions
Atributes: Amount:Double, Date:Date, Memo:String, Payee:String
Relationships: TransactionType
You should name your entities in the singular, as if you were naming
classes, and you should name the properties (attributes &
relationships) of your entities starting with a lower-case letter as
if you were naming the properties of a class.
Also, you'll probably want to use decimal numbers for monetary amounts
rather than doubles. That will let you do things like control their
rounding behavior when you manipulate them.
Thus this would be
TransactionType
Attrributes:
name: String
Relationships:
transactions: To-many to Transaction with inverse
transactionType
Transaction
Attributes:
amount: Decimal
date: Date
memo: String
payee: String
Relationships:
transactionType: To-one to TransactionType with inverse
transactions
You'll probably also want to have several other relationships on such
an entity, of course. For example, I'd probably make "payee" a to-one
relationship to some other entity rather than a string attribute,
since I'd probably have many transactions with a single payee and
there's no point in replicating that information everywhere.
For different reasons, I'd consider making "memo" a to-one
relationship to a separate Memo entity. Based on your model, it looks
like "auxiliary data" that may be associated with a Transaction. When
Core Data pulls in Transaction instances from SQLite, it will pull in
all attributes at once to preserve consistency. If you aren't always
going to use the "memo" attribute, or it could be potentially large,
you may be better off putting it on the other side of a relationship.
(Oh yeah, and I know this may just be an example, but: Double-entry
bookkeeping is the basis of modern accounting. <http://en.wikipedia.org/wiki/Double-entry_bookkeeping_system
> Instead of different types of transactions, transactions always
have debits and credits. I'll avoid going further off-topic into
accountancy though, but it might be something to look at.)
I retrieve/create/insert (not quite sure yet :)) an object from the
context, and set the values like this.
NSManagedObject *transaction = [NSEntityDescription
insertNewObjectForEntityForName:@"Transactions"
inManagedObjectContext:[self
managedObjectContext]];
This is inserting a new instance of that entity in the managed object
context.
The Transaction(tr) Object Used in the code above is defined like
this:
@interface OFXTransaction : NSObject {
Why do you even have this class? It looks like its whole purpose is
to replicate what you already have defined in your Transaction
entity. You can just use an NSManagedObject subclass to represent one
directly.
another thing I would like to understand, do relationships work like
constraints in SQL ?
in the sense that if there is no transactionType defined in the
TransactionTypes Entity,
I would not be able to insert a value in the transactionType field
of the transactions entity?
do I have to first select/fetch an object from the transactionsType
entety, and assign that to the transactionType atribute of the
transactions entety...?
Yes, you will need to insert or fetch an instance of your
TransactionType entity. You'll just take that and set it as the value
of your Transaction instance's transactionType relationship.
It's critically important to use the right terminology; you set an
attribute or a to-one relationship, and add to or remove from a to-
many relationship. You should reserve the term "insert" for adding a
new instance of an entity to a persistent store, since it has a
specific technical definition within Core Data. Similarly, "delete"
should be reserved for actually getting rid of an object, not removing
it from a relationship. Often you'll want to do both, but they are
separate concepts.
Hope this helps!
-- Chris
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
