Re: EOF Stumper (for me at least)
Re: EOF Stumper (for me at least)
- Subject: Re: EOF Stumper (for me at least)
- From: Daniel Beatty <email@hidden>
- Date: Sun, 24 May 2009 15:28:38 -0500
Greetings Dino,
You are absolutely right. I have noticed a similar issue in vertical
subclassing an object that has a many to one relation in it. I shall
provide an example, hopefully PDF pictures from OmniGraffle are
permitted. This model is motivated by "Cloud Computing Security,"
which will hopefully no cloud the subject.
Attachment:
pastedGraphic.pdf
Description: Adobe PDF document
Let us say we model this calling participants an object called
Subject. Subject has two subclasses: "User Subject" and "Group
Subject". When I attempt to subclass "Basic Entity Access" to
produce "Federation Access" I see the EO Modeling tool in WOLips
providing both the "id" for the parent "Basic Entity Access," "Allow
Operations," and "Subject". Furthermore, the column identified for
each "id" types is "id" as opposed to what the tool had produced for
them such as "permissionsID", "participantID" respectively. The
obvious trick around this is use "Horizontal" subclassing.
The point being is that this creates a violation of the multiple
primary key commandment of EOF, also. The solution is to do a bit of
massaging of the table definitions, or suffer.
Later,
Dan
On May 19, 2009, at 10:48 AM, Ricardo Strausz wrote:
Hola Lon, Chuck...
On May 18, 2009, at 9:05 PM, email@hidden
wrote:
Message: 7
Date: Mon, 18 May 2009 17:58:32 -0700
From: Chuck Hill <email@hidden>
Subject: Re: EOF Stumper (for me at least)
To: Lon Varscsak <email@hidden>
Cc: WebObjects-Dev Mailing List List <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Hi Lon,
This and your other problem cause me to suspect that you are
violating
an EOF commandment somewhere. The "it works sometimes and not
others"
is often indicative of a violation somewhere. Perhaps in this
process? I am also unsure that Propagate Primary Key is intended to
be used with a partially user controlled PK. I don't know that is
not, but it sounds suspicious.
I agree with Chuck, you are violating an EOF commandment; namely,
when you use compound primary keys, you are on your own!
I'd been using Sybase since EOF was in beta, and compound primary
keys were always a headache... I am not sure, but my guess is that
it is a locking problem.
Now I assign both (or sometimes three or more) keys by hand; indeed,
I have as part of my framework an specialised object (BAFolio) just
to do that.
If you have the proper protocol (like all PKs have the same "key-
structure"), such an object is not hard to implement and you can
forget about that problem forever... HIH.
Suerte!
On May 18, 2009, at 2:27 PM, Lon Varscsak wrote:
The worst part of this is that without any code changes sometimes it
works and sometimes it fails (meaning sometimes orderLineNumber is
written to the adaptor op properly and therefore the database...but
not always).
I have changed "propagates primary keys" and propagated it myself by
overriding the setOrderNumber method on OrderHeader (and then
passing it down to OrderDetailSale) and the error goes away
completely. I'd prefer not to do this as it really does propagate
orderNumber which I want, it just seems to be occasionally trampling
orderLineNumber.
Dino
--
email@hidden
Business Applied X Objects
http://strausz.blogspot.com
(+52-1) 55-5437-8205
_______________________________________________
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
Dan Beatty, M.S. CS (B.S. EECS)
Ph.D. Student
Texas Tech University
email@hidden
http://venus.cs.ttu.edu/~dabeatty
_______________________________________________
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