Clarifying confusion concerning collections

[David Sinclair]

Hi again,

I just want to confirm my observations/thinking regarding collections
in SQLPO.

Visualize two classes, Group and Item, as an example. They might look
like this:

@interface Group : SQLitePersistentObject
{
NSString *name;
NSMutableArray *items;
}

@interface Item : SQLitePersistentObject
{
NSString *name;
// various other ivars
Group *group;
}

Group's items would include an array of potentially hundreds of Item
instances, and Item's group would link back to the parent group.
Simple enough.

But from what I can see, if I want to load a Group object to simply
edit the name, via [Group findByPK:0] or similar, it looks like it'll
populate the items array with all of the Item instances -- potentially
loading hundreds of objects unnecessarily. Similarly, when I -save
the Group object, it'll delete and insert cross-references for all
those objects, when they haven't changed. Therefore, it seems I
should instead omit the items array.

A related confusion: when I want to populate the list of items in a
specific group, I would presumably get the item properties via a
"WHERE group=<something>" criteria. But what should the "<something>"
be? The pk of the group?

Of course, another way to do it would be to instead use the pk of the
group as the property; that'd be easy to search on. But that doesn't
feel as elegant as using the object itself (and I would want to load
the associated Group when loading an Item).

--

David Sinclair, Dejal Systems, LLC - d...@dejal.com
Dejal blog - http://www.dejal.com/blog/
Cocoa code - http://www.dejal.com/developer/
Twitter - http://twitter.com/dejal/

[Ken]

If you don't have it already, grab the SQLite Database Browser. It's
a free download that you should be able to find on the internet. It's
not the best UI by any measure, but it works. You can view the
schema, browse the data, and execute arbitrary queries. Viewing the
schema should provide some insight into how its storing your
collections, and how you might traverse parent-child relationships
depending on how you've chosen to store things. After viewing how
your objects are being stored, you may want to revise how you
represent those objects in Obj-C, as to alter how those objects are
stored.

In my particular case, I have some object A which has a few
properties. A is one-to-many with some object B, which has its own
properties. I choose not to make the list of B's available from
within A. Instead, if I need them, I query for them based on the PK
of A, which is stored in B.

Although this is slightly less convenient since you have to perform
the lookup yourself instead of having the list waiting for you in the
object, that's really your only alternative right now. Either you get
the children yourself, or you let the framework do it for you up
front, paying the associated cost in time and space for data you might
not use. If we were on a more robust persistence framework like
Hibernate where lazy-loading of relationships and more sophisticated
mappings are supported you'd have some other options, but those
facilities don't exist in SQLPO today.

KM

[David Sinclair]

Hi,

Thanks for the pointer. Yeah, I was thinking that lazy loading would
be a nice feature, but saw that SQLPO didn't do that (yet).

In the meantime, I'm sure I can live with just storing the PKs as
linkages. In my existing non-database apps I store a unique
identifier to link objects anyway, so no big difference.

David

[Oliver Scheel]

btw: What I did is to implement a very simple convenience method in
the parent class for fetching the children:

- (NSArray *)children
{
NSArray *children = [self findRelated:[Children class]];
return children;
}

If you want to add children you have to do it the old way and call the
children fetch again. For more stateful behavior you could manage a
transient NSMutableArray and implement addToChildren and
removeFromChildren.

Oliver