Yeah, same guilty party, I think ... There's a chunk of code buried
down in EOF that tracks which objects should NOT have PKs generated.
There were a couple ways it could get into that code path -- one is
related to propagates PK, and the other was if the parent and child
are in two differ
Hi,
Mike Schrag wrote:
I probably didn't respond to this thread when I posted earlier, but
this problem ended up being
inheritance-across-models-that-eof-thinks-are-in-different-databases
thing I ranted about a couple days ago (described in
http://en.wikibooks.org/wiki/Programming:WebObje
I probably didn't respond to this thread when I posted earlier, but
this problem ended up being inheritance-across-models-that-eof-thinks-
are-in-different-databases thing I ranted about a couple days ago
(described in http://en.wikibooks.org/wiki/Programming:WebObjects/EOF/
Using_EOF/Common_
Hi,
Chuck Hill wrote:
Mike Schrag wrote:
[...]
abstract (though the same problem occurs either way). When I run my
app, and create new Entity B's, the insert statements don't include
the primary key (resulting in an integrity constraint violation). If
i edit the model and simply remove the
Yeah, actually, I am surprised I haven't seen more problems as
well ... This particular framework is only deployed as part of an
internal app, so it's not under that much load. Glad I noticed this
now :)
I use Wonder's connection dictionary updater, which changes
connection dictionary in
On May 24, 2006, at 9:55 PM, Mike Schrag wrote:
The moral? If you ever do cross-model inheritance, be damn sure
your connection dictionaries are EXACTLY equal. I'm tempted to add
a check into Project Wonder that if two models have the same URL
and User but the full connection dictionaries
I am surprised that this is the only problem that his caused! What
do you use to connect the models at application startup? Our class
replaces the entire connection dictionary to ensure that this sort of
thing does not happen.
Another moral of this story is that having jdbc2info in the
Wow. Just wow. This might have been the nastiest thing (here
Nastiness is the SI unit that is equivalent to WTF's/hr) I've had to
track down in EOF that ended up having a surprisingly simple
explanation.
After literally hours of spelunking around in EOF and perusing
variables in the deb
On May 23, 2006, at 7:45 PM, Mike Schrag wrote:
I have a model in a framework that defines Entity A and a model in
my project that depends on that framework that defines Entity B as
subclass of Entity A via Horizontal Inheritance. Entity A is
abstract (though the same problem occurs eithe
Handy workaround ... I'm still curious why it's happening in the
first place, though.
On May 24, 2006, at 7:52 AM, Jean-François Veillette wrote:
You can add an entry in the userInfo dictionary of your entity,
defining the super class.
Then in the eogenerator template, you will be able to se
You can add an entry in the userInfo dictionary of your entity,
defining the super class.
Then in the eogenerator template, you will be able to set the
superclass based on that key-value.
That way, you may not tell EOModeler the exact details of java
implementation (which can be all fine in
I have a model in a framework that defines Entity A and a model in my
project that depends on that framework that defines Entity B as
subclass of Entity A via Horizontal Inheritance. Entity A is
abstract (though the same problem occurs either way). When I run my
app, and create new Entity
12 matches
Mail list logo
