On Jan 15, 2010, at 11:18 AM, Mark Ritchie wrote:
On 15/Jan/2010, at 11:04 AM, Chuck Hill wrote:
On Jan 15, 2010, at 9:44 AM, Mark Ritchie wrote:
Personally, I like the way that EOF is handling the case. It
works for reading and it correctly warns you when you attempt to
change something
On 15/Jan/2010, at 11:17 AM, Chuck Hill wrote:
> OK, good. What you are describing is also what I expect the default 5.4.3
> behaviour to be. We are all good here. :-)
Ah ok, sorry about bending your head on that one... ;-) However, always nice
to have our idea of reality shaken from time to
On 15/Jan/2010, at 11:04 AM, Chuck Hill wrote:
> On Jan 15, 2010, at 9:44 AM, Mark Ritchie wrote:
>> Personally, I like the way that EOF is handling the case. It works for
>> reading and it correctly warns you when you attempt to change something that
>> never existed in the first place. There
On Jan 15, 2010, at 11:14 AM, Mark Ritchie wrote:
On 15/Jan/2010, at 10:52 AM, Chuck Hill wrote:
I wonder if we are mis-communicating. What are you describing
below seems to be the default behavior if NOT using the delegate
method from Kelly Hawk. Is this below result from the code you
On 15/Jan/2010, at 10:52 AM, Chuck Hill wrote:
> I wonder if we are mis-communicating. What are you describing below seems
> to be the default behavior if NOT using the delegate method from Kelly Hawk.
> Is this below result from the code you posted later (Application.java)?
Oh yes, I should
On Jan 15, 2010, at 9:44 AM, Mark Ritchie wrote:
Hi Lon,
On 14/Jan/2010, at 2:21 PM, Lon Varscsak wrote:
heh, it's not. :) I also don't believe that sometimes having an
optional to-one is always a "thing to fix". However, I do understand
now that EOF doesn't handle this case much better tha
Hi Mark,
On Jan 15, 2010, at 12:08 AM, Mark Ritchie wrote:
Hi Chuck!
On 14/Jan/2010, at 1:46 PM, Chuck Hill wrote:
On Jan 14, 2010, at 3:36 AM, Mark Ritchie wrote:
Yes, I believe that's the intended behaviour... The
DatabaseContext tracks that newly created EO and throws an
exception if
Hi Lon,
On 14/Jan/2010, at 2:21 PM, Lon Varscsak wrote:
> heh, it's not. :) I also don't believe that sometimes having an
> optional to-one is always a "thing to fix". However, I do understand
> now that EOF doesn't handle this case much better than it did in WO4.
Personally, I like the way tha
Hi Chuck!
On 14/Jan/2010, at 1:46 PM, Chuck Hill wrote:
> On Jan 14, 2010, at 3:36 AM, Mark Ritchie wrote:
>> Yes, I believe that's the intended behaviour... The DatabaseContext tracks
>> that newly created EO and throws an exception if you attempt to modify and
>> then save it.
> Almost, it thr
heh, it's not. :) I also don't believe that sometimes having an
optional to-one is always a "thing to fix". However, I do understand
now that EOF doesn't handle this case much better than it did in WO4.
-Lon
On Thu, Jan 14, 2010 at 3:14 PM, Mark Ritchie wrote:
> On 14/Jan/2010, at 10:41 AM, To
On 14/Jan/2010, at 10:41 AM, Tom M.Blenko wrote:
> I think you need a better example because I'm left wondering how/when
> PartAttribute and Part rows get created and deleted. If some process outside
> your control is doing that the to-many is off the table and there are other
> issues that need
Hi Mark,
On Jan 14, 2010, at 3:36 AM, Mark Ritchie wrote:
Hi Chuck!
On 13/Jan/2010, at 5:17 PM, Chuck Hill wrote:
The Obj-C implementation is hazy in my memory. In Java, rather
than throwing a hissy fit, it will create a "dummy fault EO". That
is, an EO with all null values and no real e
I'm happy to model an optional to-one as a to-many. It almost always
results in a superior data model because it moves contention off the,
e.g., Part, table. That is good and sometimes very good (my example
is a User table with lots of rows and optional to-one's that grow
like topsy as ma
Hi Chuck!
On 13/Jan/2010, at 5:17 PM, Chuck Hill wrote:
> The Obj-C implementation is hazy in my memory. In Java, rather than throwing
> a hissy fit, it will create a "dummy fault EO". That is, an EO with all null
> values and no real existence. What Lon wants is a real null, not a dummy EO.
On Jan 13, 2010, at 5:08 PM, Mark Ritchie wrote:
On 13/Jan/2010, at 4:07 PM, Lon Varscsak wrote:
Sighing is not allowed on the list. ;)
Apparently you're having a different day then I am! ;-)
I sent an example a few minutes ago. Yes, that does sound like
what I'm describing.
Your message
On 13/Jan/2010, at 4:07 PM, Lon Varscsak wrote:
> Sighing is not allowed on the list. ;)
Apparently you're having a different day then I am! ;-)
> I sent an example a few minutes ago. Yes, that does sound like what I'm
> describing.
Your message and mine crossed paths... ;-)
Thanks for posting t
You could model it as a right-outer join and optional, but I think
that EOF is still going to have a hissy fit when it does not find the
row. Worth a try and a good bug to log with Apple if it does not work.
Chuck
On Jan 13, 2010, at 4:01 PM, Lon Varscsak wrote:
Okay, let me try to give a
I should add that that sounds what I'm talking about, but consider that you
don't always have a photo for a Talent.
-Lon
On Wed, Jan 13, 2010 at 5:07 PM, Lon Varscsak wrote:
> Sighing is not allowed on the list. ;) I sent an example a few minutes
> ago. Yes, that does sound like what I'm descr
Sighing is not allowed on the list. ;) I sent an example a few minutes ago.
Yes, that does sound like what I'm describing.
On Wed, Jan 13, 2010 at 4:56 PM, Mark Ritchie wrote:
> On 13/Jan/2010, at 2:53 PM, Lon Varscsak wrote:
> > Is there a way to model an optional to-one relationship from the
On 13/Jan/2010, at 2:53 PM, Lon Varscsak wrote:
> Is there a way to model an optional to-one relationship from the primary key
> to a primary key of another object?
*sigh* As with so many conversations theses days... What are you trying to do?
My initial response is look at how the Movies.eomo
Okay, let me try to give an example (although a contrived example).
Entity: Part (PK: partNumber)
Entity: PartAttributes (PK: partNumber)
It's a to-one relationship from Part to PartAttributes, but the
part_attributes table doesn't have to have a row for a given part. If this
were a to-many re
Modelling it as FK to PK seems like the way to go, unless I am
misunderstanding what you need.
On Jan 13, 2010, at 3:24 PM, Lon Varscsak wrote:
Yes it is the same PK in both tables but there are no rows in the
relationship. This is a pretty common practice and I just hate
modeling a to-m
Yes it is the same PK in both tables but there are no rows in the
relationship. This is a pretty common practice and I just hate modeling a
to-many and then provide interfaces as a to-one.
On Wed, Jan 13, 2010 at 4:14 PM, Travis Britt wrote:
> Short answer: no. Is the PK not really a PK? If it
Short answer: no. Is the PK not really a PK? If it is a real PK, how are there
rows without it?
On Jan 13, 2010, at 5:53 PM, Lon Varscsak wrote:
> Is there a way to model an optional to-one relationship from the primary key
> to a primary key of another object?
_
Is there a way to model an optional to-one relationship from the primary key
to a primary key of another object?
-Lon
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Hel
25 matches
Mail list logo
