Re: Subset of relationship
Re: Subset of relationship
- Subject: Re: Subset of relationship
- From: Ian Joyner <email@hidden>
- Date: Wed, 10 Aug 2005 10:27:11 +1000
Where you have entities which share much in common but just a few
differences – why this sounds like a job for inheritance (or is that
super.inheritance).
EOModeler provides support for three different kinds of database
inheritance model and these are described in Chapter 7 of Using
EOModeler. For the message case, I think you only need single table
inheritance since all the fields are the same (no new ones introduced
in subentities). Set a one character status field to 'S' for sent and
'D' for draft and then subclass the Message entity into Sent_message
and Draft_message, with the Table set to MESSAGE (so they are stored
in the single table) the Qualifiers in the entity inspector set to
(status = 'S') and (status = 'D') respectively.
Setting the qualifiers in the Advanced Entity Inspector gives you
automatic subsets. When a message is sent, just change the status to
"S" and it automatically appears in the Sent_message entity and not
in the Draft_message entity, but you can get the entire list with
access via the Message entity. There is also no need to move records
between different DB tables, so your idea of using a single table is
excellent.
Oh, and don't forget to use prototypes (defined in a table
EOPrototype) for all your attributes to keep them consistent and
easily maintainable.
Hope that helps
Ian Joyner
Sportstec
On 10/08/2005, at 6:44 AM, 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.
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.
3. the model should be redesigned so Messages and Drafts are set
apart.
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:
40sportstec.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