On 31 May 2007, at 07:34, Jean Pierre Malrieu wrote:
This as not always been so clear. In Apple's WO formation support
material (around 2002), they did talk about a method of dealing
with object editing and backtracking: they call it "deferred
insertion". Basically, they say you can set at
It depends on what your use case is. You can manually do whatever
makes sense for you (and it will lock for you regardless), but in
general, we can't really just do this in any easy way. In most cases
a component gets passed in an EO or an array of EOs, and you don't
know what EC it origi
In this instance, couldn't you have all the EOs you're using in the
defaultEC then just transfer them into ERXEC via localInstancesOfObjects?
On 5/31/07, Mike Schrag <[EMAIL PROTECTED]> wrote:
2) Closely related to that, it's very common to do a bunch of things in
close succession. Think of r
This ended up a lot longer than I originally planned, but here goes:
So the last one is something I added in after watching locking
behavior in Wonder and profiling. With defaultAutomaticLockUnlock
turned on, basically what Wonder will do is ensure that before every
call you make on an EC,
Oh yes, and one more thing: You need to set up your system
properties in the following way:
er.extensions.ERXApplication.useEditingContextUnlocker=true
er.extensions.ERXEC.defaultAutomaticLockUnlock=true
er.extensions.ERXEC.useSharedEditingContext=false
er.extensions.ERXEC.defaultCoalesceAutoL
The only place where there are MAYBE some pitfalls (and this is just
theoretical because I haven't done much testing of this case) is
passing EO's between threads. I instead pass GID's, or use
ERXEOControlUtilities.convertGIDtoEO/convertEOtoGID if I have
dictionaries or arrays of them.
m
Hey Ted,
That's how I've been doing it for a bit now, and so far, so good! It
certainly doesn't HURT to lock and unlock editing contexts created
through ERXEC, but the authors of that whole business have done a
great job in making it just as easy to use (locking-wise) as the
default edit
So, if I use ERXEC is there anything else I have to concern myself about?
Is all the locking taken care of that I need to worry about?
IOW, I can just go into my code and any instances I have of a defaultEC for
creating and inserting objects I can simply use ERXEC keeping in mind that I
need to r
A) Clearly document the issue from the outset of the product.
Without an active third party community that enlightened these
issues, I feel sure I would have never been aware of them, and
probably would have switched development platforms in frustration
by now.
Cough. Cough.
http://develope
While not fully addressing this issue, Wonder actually does have a
cool feature where it computes hash codes for items in a
WORepetition and modifies the element id to include this hash,
which allows structural
... you have to turn this on, btw -- See the javadoc on
ERXWORepetition (http://
Why can't some sort of architectural "checksum" be calculated on
the nodes of the template object graph as the template is first
built in the appendToResponse, stored in the WOContext for that
page and compared against any subsequent rebuilding of the
template, throwing an exception with a
Hi, Mike, et al,
On May 30, 2007, at 6:49 PM, Mike Schrag wrote:
I've seen that document as well, but I noticed the date on it was
the latter half of 2005. I read all of the documentation Apple
had regarding WebObjects back in 2000, and I even managed to get
my hands on the training manua
It is indirect. Access to all EO values is via storedValueForKey.
This then eventually calls willReadRelationship, but willRead is
called first. Same for willChange().
EOCustomObject subclasses might be different. Does anyone still use
them?
Chuck
On May 30, 2007, at 3:41 PM, Mike S
I've seen that document as well, but I noticed the date on it was
the latter half of 2005. I read all of the documentation Apple had
regarding WebObjects back in 2000, and I even managed to get my
hands on the training manuals for the courses they used to offer on
WebObjects, and I don't e
I THINK willReadRelationship is probably the same?
Looks like I'm wrong on this one -- it doesn't appear to ...
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Un
Cough. Cough.
http://developer.apple.com/documentation/WebObjects/
Enterprise_Objects/EnterpriseObjects/chapter_3_section_13.html#//
apple_ref/doc/uid/TP30001011-DontLinkChapterID_8-TPXREF146
And I quote, "Note that immediately after the enterprise object is
created, it is inserted into a
willChange calls willRead (i just happened to check this) ... I THINK
willReadRelationship is probably the same? Not sure about that offhand.
On May 30, 2007, at 6:32 PM, Lachlan Deck wrote:
On 31/05/2007, at 8:15 AM, Chuck Hill wrote:
On May 30, 2007, at 12:57 PM, Steven Mark McCraw wrote
On 31/05/2007, at 8:15 AM, Chuck Hill wrote:
On May 30, 2007, at 12:57 PM, Steven Mark McCraw wrote:
B) Programmatically constrain programmers to follow those rules.
Since changing the state of an object is so catastrophic if the
object is not in the pool that enables it to be tracked, why
On May 30, 2007, at 12:57 PM, Steven Mark McCraw wrote:
I definitely don't want to strike up a semantic argument on a list,
but just to clarify: I think it's weak due to documentation and
implementation. I can fully appreciate the complexity of the
problem set EOF is solving. Tracking s
Although I do agree the defaultEditingContext is not the best way to
go, I didn't have problems with it, and I used it for years.
However, I had navigation methods in my superclass that would (by
default) either abort the navigation if there were unsaved changes,
or simply revert (assuming
On 30.05.2007, at 13:03, Steven Mark McCraw wrote:
You have stumbled upon what I believe to be one of the biggest
weaknesses in EOF, and the solutions are (again, in my opinion)
terrible.
Hmmm. Interesting opinion. I always see the concept of
"sandboxes" (editingContexts) as one of the bi
I definitely don't want to strike up a semantic argument on a list,
but just to clarify: I think it's weak due to documentation and
implementation. I can fully appreciate the complexity of the problem
set EOF is solving. Tracking state is a bear, and I can appreciate
the necessity of hav
On 30.05.2007, at 12:41, Ted Archibald wrote:
Originally in my program I was using the defaultEC to create and
insert new objects, but then started to notice I had alot of null
objects in my DB. Users are creating an object, then doing nothing
with it, then it is committed to the DB when th
You have stumbled upon what I believe to be one of the biggest
weaknesses in EOF, and the solutions are (again, in my opinion)
terrible.
I don't really see this as a big weakness of EOF ... It has to be
able to track changes, and without an editing context, it's not in a
"transaction", and
Hi Ted,
You have stumbled upon what I believe to be one of the biggest
weaknesses in EOF, and the solutions are (again, in my opinion)
terrible. As you've noticed, if you insert things into an editing
context as they are created, you end up with a bunch of uninitialized
objects in the da
On May 30, 2007, at 11:41 AM, Ted Archibald wrote:
Originally in my program I was using the defaultEC to create and
insert new objects, but then started to notice I had alot of null
objects in my DB. Users are creating an object, then doing nothing
with it, then it is committed to the DB w
Originally in my program I was using the defaultEC to create and insert new
objects, but then started to notice I had alot of null objects in my DB.
Users are creating an object, then doing nothing with it, then it is
committed to the DB when the defaultEC is saved at some later point.
Is this wh
On Apr 6, 2007, at 3:23 PM, Kevin Windham wrote:
I attempted to implement a nested editing context and ran into a
problem. I would suspect I am violating a rule of some kind, but I
don't know what it would be. My first attempt failed. My editing
page would not load and it would eventually
or locking the child editing context
2. When a child EC is locked, it locks it's parent.
I think that #2 is what they meant by "Child (nested) editing
contexts use their parent’s lock."
Chuck
--
Here are a few additio
locking objects than those
built in to Java. These objects provide both you and Enterprise
Objects with more control over the scope of critical regions within
applications. This reduces contention and the possible scenarios that
can generate deadlocks.
Child (nested) editing contexts use
Since I was under some time constraints with this section of my
program, I ended up using a temporary object and copying the
properties to the actual object if the user saves. I could not figure
out what I was doing wrong with the nested context. I also could not
get it to work at all if I
Kevin,
It would be much more helpful if you could post the exception.
Ken
On Apr 6, 2007, at 6:23 PM, Kevin Windham wrote:
I attempted to implement a nested editing context and ran into a
problem. I would suspect I am violating a rule of some kind, but I
don't know what it would be. My fir
I attempted to implement a nested editing context and ran into a
problem. I would suspect I am violating a rule of some kind, but I
don't know what it would be. My first attempt failed. My editing page
would not load and it would eventually time out and give "no instance
available". I remov
Kevin,
I'm having a little difficulty with your nomenclature and
prepositions :) , but in general, what you're saying is correct.
Just remember, when you perform a saveChanges() on the child EC, the
changes will only be committed to the parent EC. To get your changes
to the DB, that EC
I am trying to work out how to use a nested editing context in my app.
I have an object that has a relationship to another object that it
owns. I am currently directing the user to another page to edit the
owned object, and need to implement a nested context to make save and
cancel work pro
On 26.03.2007, at 11:16, Chuck Hill wrote:
to avoid null pointer exceptions all over the place (and/or to
avoid having to write lots of code to check that the relationships
were non-null). I took the following steps:
You should never need to worry about that. If the to-many
relationshi
to avoid null pointer exceptions all over the place (and/or to
avoid having to write lots of code to check that the relationships
were non-null). I took the following steps:
You should never need to worry about that. If the to-many
relationships are null, you have overridden awakeFromIns
iterally
getting nowhere doing even simple things with it. Any advice on
what approach I should take?
There is no need for a workaround. Somehow, somewhere, you are
abusing EOF. Even if you work around this, EOF will just lie in
wait and take its revenge elsewhere. I used nested editing
approach I should take?
There is no need for a workaround. Somehow, somewhere, you are
abusing EOF. Even if you work around this, EOF will just lie in
wait and take its revenge elsewhere. I used nested editing
contexts. I know lots of others do too. They work just fine if
you play nice with
Craw wrote:
Hi all,
I have recently bumped into a problem with using nested editing
contexts to accomplish add/edit workflows. What I'm doing seems
simple enough, and correct from my understanding of the
documentation. I'm creating a nested editing context:
EOEditingContext n
There is no need for a workaround. Somehow, somewhere, you are
abusing EOF. Even if you work around this, EOF will just lie in
wait and take its revenge elsewhere. I used nested editing
contexts. I know lots of others do too. They work just fine if
you play nice with EOF.
Get the
just lie in wait
and take its revenge elsewhere. I used nested editing contexts. I
know lots of others do too. They work just fine if you play nice
with EOF.
Chuck
On Mar 24, 2007, at 6:00 PM, Chuck Hill wrote:
Are you locking the child EC?
On Mar 24, 2007, at 2:30 PM, Steven Ma
The only other possibility is that you are misusing EOF by violating
one of these:
http://en.wikibooks.org/wiki/Programming:WebObjects/EOF/Using_EOF/
The_EOF_Commandments
Chuck
On Mar 25, 2007, at 1:42 PM, Steven Mark McCraw wrote:
Ok, I have spent several hours making sure that I lock all
Ok, I have spent several hours making sure that I lock all of my
editing contexts (except the session's default EC), and I have
enabled all of the project wonder stuff that helps prevent deadlocks,
and I'm still getting the exact same behavior. Here's what I'm doing:
I moved the nested edi
Isn't that supposed to do automatic locking/unlocking for you, or
is there something I need to add?
Not by default. You have to add the Properties that define what
locking behavior you want. I posted the settings I use a couple of
weeks ago ... Search for that on the list, and also read the
ly getting nowhere doing even simple
things with it. Any advice on what approach I should take?
Thanks,
Mark
On Mar 24, 2007, at 6:00 PM, Chuck Hill wrote:
Are you locking the child EC?
On Mar 24, 2007, at 2:30 PM, Steven Mark McCraw wrote:
Hi all,
I have recently bumped into a pr
Are you locking the child EC?
On Mar 24, 2007, at 2:30 PM, Steven Mark McCraw wrote:
Hi all,
I have recently bumped into a problem with using nested editing
contexts to accomplish add/edit workflows. What I'm doing seems
simple enough, and correct from my understanding o
Hi all,
I have recently bumped into a problem with using nested editing
contexts to accomplish add/edit workflows. What I'm doing seems
simple enough, and correct from my understanding of the
documentation. I'm creating a nested editing context:
EOEditingContext nest
48 matches
Mail list logo
