Re: Subset of relationship
Re: Subset of relationship
- Subject: Re: Subset of relationship
- From: "Jerry W. Walker" <email@hidden>
- Date: Tue, 9 Aug 2005 19:49:43 -0400
I think Ken's advice is excellent. I will simply augment it with some
code in case you're having trouble getting started with that.
On Aug 9, 2005, at 5:15 PM, Ken Anderson wrote:
Emerson,
You're not doing anything really wrong - it just takes a little
time to understand the tool.
The way to choose the approach to take is often a function of the
number of records you expect to be processing and the split between
the 2 different groups. I responded to each of your ideas below.
Ken
On Aug 9, 2005, at 4:44 PM, Emerson wrote:
Hello friends,
I have a very basic question, mainly because I've just recently
started
developing in WO. Although I have some ideas, I'd like to get some
feedback in order to use best practices right from the beginning.
Consider a model where you have a number of entities. In that model,
User records users and Message records messages sent and drafts
saved by
users. I decided not to split messages sent and drafts saved in two
different entities because several properties and relationships would
have been duplicated; moreover, since a draft can become a
message, it
sounded inefficient to me having to create a new message and
literally
copy each and every property/relationship whenever a draft was
sent. It
sounds like just a state change.
Nothing new so far.
It happens that I would like to browse either all messages sent or
all
drafts saved by a user, but not both at the some time. EOF gives me a
NSArray of Messages, containing both messages sent and drafts saved,
resulting from the relationship with the entity Message.
What's the most recommended way of getting a NSArray with only the
drafts saved or messages sent?
1. using an in-memory operation with java.util.Enumerator to split
messages sent and drafts saved (by looking at the value of a "state"
property); this approach sounds inefficient, since all messages are
fetched and comparisons are made in memory; databases are probably
better at that job. By the way, I feel this alternative should use
something like NSKeyValeCoding and NSKeyValueCodingAdditions
instead of
enum, but I just can't figure out how.
This is sometimes a good approach if you want to keep your eomodel
simple and you don't think you'll have very many objects. It also
only works well if there will be a reasonably equal number of both
so that one side doesn't become inefficient (like looking for 1
Draft inside a box of 4000 Messages).
If you go with an in memory array, I would suggest using
EOQualifier's static methods, either
public static NSArray filteredArrayWithQualifier(NSArray array,
EOQualifier qualifier)
or
public static void filterArrayWithQualifier(NSMutableArray
array, EOQualifier qualifier)
The former applies a qualifier to a static array (say, your Message
array) and returns a new array containing the subset of qualified
values (say, your drafts). The latter applies a qualifier to a
mutable array and reduces that array to a qualified subset.
So presuming you have some state variable in Message, such as
isDraft, you might write it as:
EOQualifier getDraftsQualifier =
EOQualifier.qualifierWithQualifierFormat("isDraft = 'Y'", null);
NSArray theDrafts = EOQualifier.filteredArrayWithQualifier
(aUser.messages(), getDraftsQualifier);
Alternatively, you could write it as:
EOQualifier getDraftsQualifier =
EOQualifier.qualifierWithQualifierFormat("isDraft = 'Y'", null);
NSMutableArray theDrafts = aUser.messages().mutableClone();
EOQualifier.filterArrayWithQualifier(theDrafts, getDraftsQualifier);
I would prefer the former unless there were a good reason for having
the mutable array.
2. creating a fetch specification in the entity Message which returns
all drafts for a given userid. In the class User, a method named
draftsFS could be defined so that it creates a new fetch
specification
by assigning the userid obtained with EOUtilities to the raw fetch
specification defined in the entity Message; the application would
be in
charge of doing the fetch. This approach just "forgets" the default
relationship.
I try to avoid using this approach, since it takes you out of the
EOF loop, and you lose some of EOF's features, especially things
like batch faulting. It does, however, have its place, especially
if the query is more complex than what you're doing.
I agree with Ken in generally avoiding this approach, but more so
because it seems to be the product of "result sets" thinking. I think
a lot about database artifacts like userId when creating my EOModel,
but try my best to forget about them later in the depths of my OO
code. I do my best to avoid making them class properties.
However, a fetch specification could be created to obtain a given
user's drafts. For a fetch this simple, however, I would tend to one
of the EOUtilities shortcuts, such as objectsMatchingValues():
EOEditingContext ec = xx; // where xx = <some editing context,
such as session().defaultEditingContext if in a WOComponent>
NSDictionary keyValueDict = new NSDictionary(new Object[] {myUser,
"Y"}, new Object[] {"user", "isDraft"}) ;
NSArray usersDrafts = EOUtilities.objectsMatchingValues(ec,
"Message", keyValueDict);
3. the model should be redesigned so Messages and Drafts are set
apart.
This is the one I'd choose for your particular situation, but not
in the way you think. I would have an entity Message, with 2 sub-
entities - Draft and Sent (or something like that). If you had a
draft flag, I would put restricting qualifiers on the entity like
this:
Message draft = NULL
Draft draft = 'Y'
Sent draft = 'N'
I would make sure that draft is never NULL, so Message never gets
instantiated (it should also be marked as an Abstract Entity).
You can now have 2 relationships, each pointing to the proper
entity, and you will only get the right results for each one. If a
message goes from being a draft to real, updating the Sent property
will do the right thing next time you fetch. You can implement
most of your code in the Message class so that both entities share
most of the code (only override what you need to in Draft & Sent).
EOF gives you three ways to map such subclasses onto the tables of an
RDB:
* vertical inheritance - a table for each of Message, Draft and
Sent with only the data in Draft and Sent that differentiate them.
* horizontal inheritance - a table only for Draft and for Sent in
which the Message(s) are partitioned across these two tables.
* single table inheritance - a table for Message in which the rows
can be distinguished by a state variable such as Ken described.
Now that you have the buzzwords for these, it's easy enough to look
them up in the EOF documentation. I think your problem argues
strongly for single table inheritance, since the only difference
between the two subclasses is the value of the state variable.
Since I'm having problems with such a basic issue, I know I must be
doing something really wrong and that's why I decided to request your
opinions.
Again, I agree with Ken. WO and EOF provide rich language with a
cornucopia of "phrases" to say the same thing. It takes a while to
figure out the appropriate idioms.
Best regards,
Jerry
--
__ Jerry W. Walker, Partner
C o d e F a b, LLC - "High Performance Industrial Strength
Internet Enabled Systems"
email@hidden
212 465 8484 X-102 office
212 465 9178 fax
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden