Re: Subset of relationship
Re: Subset of relationship
- Subject: Re: Subset of relationship
- From: Ken Anderson <email@hidden>
- Date: Tue, 09 Aug 2005 17:15:00 -0400
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).
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.
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).
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.
thanks in advance,
Emerson
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40anderhome.com
This email sent to email@hidden
_______________________________________________
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