On Oct 13, 2009, at 3:17 AM, Jon Hull wrote:
You don't need proxies or NSProxy for this. You can just use a
delegate. Off the cuff, I might consider implementing a protocol
on your immutable objects for methods like "currentLocation" and
"currentPlayer" which vector through a semi-global
The project is a game engine which has 2 graphs. The first is a tree
of events that represent the story. Each "event" in the story is an
immutable object, and there is a special event which represents a
series of events to run in order and one which represents branches
that the player has to
The project is a game engine which has 2 graphs. The first is a tree
of events that represent the story. Each "event" in the story is an
immutable object, and there is a special event which represents a
series of events to run in order and one which represents branches
that the player has to
Yes, well it is fairly complex... but it looks like core data is
not a good fit since a basic requirement is that I need it to store
nested arrays of immutable objects and keep the order (I also need
to allow those objects to be inserted at multiple points in the
array). The immutability a
On Oct 12, 2009, at 1:31 PM, Jon Hull wrote:
3) What is the best way of connecting objects from different
stores? I am considering giving them UUIDs and then storing that as
a reference. Then setting a transient property based on that in -
awakeFromFetch. Alternatively, I could store it a
Ok, let me ask some more specific questions and see if that gets a
response... Feel free to respond if you only know the answer to 1 or
2 of these.
1) Can I count on a to-many relationship keeping the order of the
managedObjects it points to? The order is very important in this
case, and I need
On Oct 12, 2009, at 4:32 PM, Jon Hull wrote:
I have spent the last 48 hours (re)reading core data docs. My head
is swimming in docs.
Understandable. It's a complicated technology (especially when you
consider its interaction with Bindings).
The short answer is yes, I understand to giv
On Oct 12, 2009, at 12:46 PM, I. Savant wrote:
On Oct 12, 2009, at 3:31 PM, Jon Hull wrote:
1) Can I count on a to-many relationship keeping the order of the
managedObjects it points to? The order is very important in this
case, and I need a way to ensure that the order does not change
wh
On Oct 12, 2009, at 3:31 PM, Jon Hull wrote:
1) Can I count on a to-many relationship keeping the order of the
managedObjects it points to? The order is very important in this
case, and I need a way to ensure that the order does not change when
the object is saved and reloaded.
No. Thi
Ok, let me ask some more specific questions and see if that gets a
response... Feel free to respond if you only know the answer to 1 or
2 of these.
1) Can I count on a to-many relationship keeping the order of the
managedObjects it points to? The order is very important in this
case, an
On Dec 18, 2008, at 11:18, Michael B Johnson wrote:
I guess that's my question, though. Why is that a bad thing, to
have three relationships from on entity all pointing to another
entity, which is only pointing to the other entity once?
It's not a *bad* thing, but the model editor won't le
On Dec 18, 2008, at 11:04 AM, mmalc Crawford wrote:
On Dec 18, 2008, at 10:47 AM, Michael B Johnson wrote:
I have an entity (let's called it MyThing) that has an optional
parentThing relationship. I'm interested in MyThings that either
don't have their parent set, ("parentThing == NIL")
On Dec 18, 2008, at 10:47 AM, Michael B Johnson wrote:
I have an entity (let's called it MyThing) that has an optional
parentThing relationship. I'm interested in MyThings that either
don't have their parent set, ("parentThing == NIL") or have their
parent set to themselves ("parentThing
Getting back into Core Data over the holidays, and I've got a few
questions. First, the easy one:
I have an entity (let's called it MyThing) that has an optional
parentThing relationship. I'm interested in MyThings that either
don't have their parent set, ("parentThing == NIL") or have t
On 28-Oct-08, at 2:01 AM, Keary Suska wrote:
1. Confirmation clarification: do I understand correctly,
considering typical RDBMS data integrity rules, that for most to-one
relationships, I would set the delete rule to "no action", since
deletion of the "many" item should not effect the "on
On Oct 27, 2008, at 2:55 PM, I. Savant wrote:
1. Confirmation clarification: do I understand correctly, considering
typical RDBMS data integrity rules, that for most to-one
relationships, I
would set the delete rule to "no action", since deletion of the
"many" item
should not effect the "o
On Oct 27, 2008, at 4:31 PM, Keary Suska wrote:
1. Confirmation clarification: do I understand correctly,
considering typical RDBMS data integrity rules, that for most to-one
relationships, I would set the delete rule to "no action", since
deletion of the "many" item should not effect the "
> 1. Confirmation clarification: do I understand correctly, considering
> typical RDBMS data integrity rules, that for most to-one relationships, I
> would set the delete rule to "no action", since deletion of the "many" item
> should not effect the "one" item?
Impossible to generalize, but gene
1. Confirmation clarification: do I understand correctly, considering
typical RDBMS data integrity rules, that for most to-one
relationships, I would set the delete rule to "no action", since
deletion of the "many" item should not effect the "one" item?
2. How do I best implement custom UUI
All object ivars (except the array for the next lower-level),
including those of Shapes,
reside in dictionaries. These have certain required properties plus many
optional properties, some not currently defined and some possibly not even
know to the containing object.
Assuming a large fraction
> If you're designing a data model using Core Data, it's actually very
> useful to step back and look at your data the way a layperson would.
> By this I mean forget about classes and inheritance and all that
> stuff. You can come back to it later, but the main thing is to look at
> the problem in
Hi Gordon,
If you're designing a data model using Core Data, it's actually very
useful to step back and look at your data the way a layperson would.
By this I mean forget about classes and inheritance and all that
stuff. You can come back to it later, but the main thing is to look at
the
On Fri, Jun 6, 2008 at 8:06 PM, Gordon Apple <[EMAIL PROTECTED]> wrote:
>Our data hierarchy has six objects, all of which inherit from "BaseList"
> which contains a dictionary (props) and an array (subList). These lists are
> chained (i.e., the six subclasses). So in the first-attempt data mo
Our data hierarchy has six objects, all of which inherit from "BaseList"
which contains a dictionary (props) and an array (subList). These lists are
chained (i.e., the six subclasses). So in the first-attempt data model,
baselist.sublist is a one-to-many looping back to BaseList.
However
On 6 Jun 2008, at 16:12, David Wilson wrote:
On Fri, Jun 6, 2008 at 6:59 PM, Gordon Apple <[EMAIL PROTECTED]> wrote:
I'm currently trying to evaluate whether or not Core Data is a
viable
storage system in our application. Although I've been through the
tutorials, Refs, and searches, I sti
On Fri, Jun 6, 2008 at 6:59 PM, Gordon Apple <[EMAIL PROTECTED]> wrote:
>I'm currently trying to evaluate whether or not Core Data is a viable
> storage system in our application. Although I've been through the
> tutorials, Refs, and searches, I still have questions:
>
> 1. Our data hierarchy
I'm currently trying to evaluate whether or not Core Data is a viable
storage system in our application. Although I've been through the
tutorials, Refs, and searches, I still have questions:
1. Our data hierarchy model does not seem to fit into the Core Data object
model. (At least I haven'
27 matches
Mail list logo
