Re: Strange _EOCheapCopyMutableArray crash
Hi Chuck (and others who might see what this problem is),
On 27/03/2007, at 3:09 AM, Chuck Hill wrote:
Hi Ian,
On Mar 25, 2007, at 9:43 PM, Ian Joyner wrote:
I'm getting a crash in the following code:
public boolean is_unassigned () {
// editingContext ().refaultObject (this);
log.info ("is_unassigned " + this.groups ());
boolean result = true;
java.util.Enumeration e = groups
().objectEnumerator ();
while (result && e.hasMoreElements ()) {
Group_Member gm = e.nextElement ();
if (gm.group ().parent_group () != null && gm.end_date () ==
null) result = false;
}
return result;
}
caused by groups on line 5 being a _EOCheapCopyMutableArray.
Um, no. That just means it is an unfired array fault. See below
for actual cause.
Sorry, did not what to imply that firing a fault was the problem -
merely that is where it is occurring.
The enclosing object for this method was originally created in
another editingContext (being Java client, in another window), so
I suspect something to do with the groups being in another (now
gone) editing context. It does not happen all the time though,
only on the first object created - if I restart the application,
further objects can be added without problem.
It could he a Java Client related bug. It also sounds like that
can happen with incorrect locking of editing contexts or general
EOF abuse. I seem to be saying that a lot lately... :-)
Something has messed up the object graph and / or the local EC
representation.
I suspect some EOF abuse on my part since the main screen was adding
a member, creating the member screen, copying the member and groups
in, and create the join table objects. I changed this to actually
create all these in the member screen editing context, tried a few
other things, but still this occurs. This is after the member screen
does saveChanges and closes, and when the member is displayed in the
list in the main screen. It seems the context information of the
member screen is not getting propagated to the main screen, although
firing the faults should rectify this.
This problem only occurs when inserting the first member in an empty
group – members after that work fine.
Here is the main screen code:
public void create_member (Group in_group) {
// IJ Somehow, I think the copy_into_editing_context is very messy
here. Is there a simpler
// more sure shot way of achieving this?
if (in_group != null) {
if (!in_group.is_archived ()) {
Client_configuration.update_memory_statistics
();
Member_interface_controller member_controller = new
Member_interface_controller ();
EOFrameController.runControllerInNewFrame (member_controller,
"New Member");
member_controller.new_member (top_group,
in_group);
} else {
EODialogs.runErrorDialog ("Can't add", "Can't add members to an
archived group.");
}
}
}
and the member screen code:
public void new_member (Group top_group, Group into_group) {
adding = true;
displayGroup ().insert ();
add_to_group ((Group)Service.copy_into_editing_context (top_group,
editingContext ()));
if (into_group != top_group) {
add_to_group ((Group)Service.copy_into_editing_context
(into_group, editingContext ()));
}
}
public void add_to_group (Group to_group) {
Group_Member gm = new Group_Member ();
// This doesn't work either... see Member.is_unassigned problem.
// Group_Member gm = (Group_Member)
EOClassDescription.classDescriptionForEntityName
("Group_Member").createInstanceWithEditingContext (null, null);
editingContext ().insertObject (gm);
gm.addObjectToBothSidesOfRelationshipWithKey (to_group,
"group");
gm.addObjectToBothSidesOfRelationshipWithKey ((Member)displayGroup
().selectedObject (), "member");
}
and copy_into_editing_context is:
public static Object copy_into_editing_context (EOGenericRecord
from_object, EOEditingContext into_ec) {
if (from_object == null) log.error ("from_object is null");
if (into_ec == null) log.error ("into_ec is null");
return into_ec.faultForGlobalID (global_id (from_object),
into_ec);
}
I've checked the model and the inverse relationships are in place:
Member <-->> Group_Member <<--> Group
A fix that seems to work is the commented out line 'editingContext
().refaultObject (this);', but this seems to me li
Re: Problem with nested editing contexts
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 relationships are null, you have overridden awakeFromInsertion (and / or awakeFromFetch) and failed to call super.awakeFromInsertion / awakeFromFetch. EOF automatically sets these to empty arrays in the super implementation. What I do to help preventing that, is creating awakeFromInsertion and awakeFromFetch in my EOGenerator template as a method stub that only calls super() and has a comment for "initialize your object here ...". So I only have to put in the code at that place and can't possibly forget to call super(). cug ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
Re: Problem with nested editing contexts
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 awakeFromInsertion (and / or awakeFromFetch) and failed to call super.awakeFromInsertion / awakeFromFetch. EOF automatically sets these to empty arrays in the super implementation. b) updated my EOGenerator templates so that the generated code checks for null in the to-many relationship accessors and returns an empty array if it is null You should not need to do that, you still have a problem to hunt down. I am not sure where to look next. I have double checked, and for sure I am calling super's implementation on every method that I override, but I still get null pointer exceptions if I don't explicitly check the relationship accessors. I always thought this was stupid EOF behavior, but had no choice but to override my templates, because it was the behavior I was getting. It might very well be thanks to something I'm doing elsewhere, but not sure where else to looks because I've never been violating any of the rules set forth by the vendor, and now I'm not violating any rules set forth by the non-vendor user community (that I'm aware of). But at any rate, at least the code works in predictable ways now, and the added code in my templates shouldn't impose a noticeable overhead, even if it's theoretically unnecessary. Next time I can afford to spend a few hours researching the problem, I will have another look and see if I can track down something else, or else start an entirely new project to see if I can replicate the behavior there and work backwards from that. I'll let you know and post to the list if I find anything from those exercises. Thanks again for the help! Mark ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
Re: Problem with nested editing contexts
Steven, If you were getting null pointers on your to-many relationships, you are most likely overriding awakeFromInsertion without calling super on that entity. Ken On Mar 26, 2007, at 1:09 PM, Steven Mark McCraw wrote: Hi Chuck, As it turns out, I was abusing EOF (although not in a way that has ever been documented by Apple, to my knowledge). In my EOModeler generation template, I was initializing all of the the to-many relationships to empty (but non-null) arrays in the generated constructor 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: a) started using EOGenerator b) updated my EOGenerator templates so that the generated code checks for null in the to-many relationship accessors and returns an empty array if it is null Lo and behold, that fixed the problem. It's frustrating to me that there are so many gotchas in the framework that make it break in very basic places and that have never, ever been documented by Apple (to my knowledge), so much to the point that I have come very close to just giving up WebObjects development all together. But I'm feeling a lot better recently thanks to the support of people like yourself and (what seems to be) a helpful growing user community containing people like the project wonder guys. I feel like WebObjects is once again becoming a good useable, viable development platform in spite of Apple's loathsome lack of support for the product, because of a user community that is taking up the slack. Thanks! Mark On Mar 26, 2007, at 12:53 PM, Chuck Hill wrote: On Mar 24, 2007, at 9:37 PM, Steven Mark McCraw wrote: Hi Chuck, That's was a good thought, and actually I was not locking the child EC. It still strikes me as bizarre that the responsibility of locking and unlocking the editing context is left up to the programmer, but that's just me griping. I am not sure what the original rationale for not providing something at the WOSession level to manage more editing contexts. Also, it looks from the output like ERXEC is getting used (although I haven't done anything explicitly other than importing the project wonder frameworks and subclassing ERXApplication and ERXSession). Isn't that supposed to do automatic locking/ unlocking for you, or is there something I need to add? Could ERXEC be part of the problem? I modified my code by adding a nestedEC.lock() before the saveChanges, and a nestedEC.unlock() after, but to no avail. I still got the same behavior. Any other thoughts about what I might be doing wrong? It seems like such a simple thing I'm trying to do... I trust you have seen Mike's message on this. Alternately, is there any workaround other than storing attribute values in local instance variables which are then just copied into the EO itself right before the save is committed? Would it really be such a terrible idea just to not insert the EO into an editing context until you know you're ready to save? A very terrible idea. Unless, of course, you want to spend even more quality debugging time with your app. ;-) I keep reading things that say that this is a terrible idea, but I've actually been doing it for years with no apparent problems. We call that luck. But because of all the posts, etc. that say it's a bad idea, I'm trying to use the nested EC technique, but quite literally 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 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 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 of the documentation. I'm creating a nested editing context: EOEditingContext nestedEC = new EOEditingContext (session.defaultEditingContext); and then creating my EOs in this. When it's time to save, I do the following: nestedEC.saveChanges(); session.defaultEditingContext().saveChanges(); This seems to work fine with newly created items. The problem comes when I try to do that on an item that has been modified. I have printed out a few things within the code to confirm this: when the nested editing context saves its changes, it's supposed to push them into its parent context (or so I thought), but this is definitely not happening. Is this a well known issue? Has anyone seen this before? Am
Re: Problem with nested editing contexts
On Mar 26, 2007, at 10:09 AM, Steven Mark McCraw wrote: Hi Chuck, As it turns out, I was abusing EOF Ah ha! You will grow hair your palms if you keep doing that! :-P (although not in a way that has ever been documented by Apple, to my knowledge). In my EOModeler generation template, I was initializing all of the the to-many relationships to empty (but non- null) arrays in the generated constructor Yes, setting values in the constructor is a good way to annoy EOF. 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 awakeFromInsertion (and / or awakeFromFetch) and failed to call super.awakeFromInsertion / awakeFromFetch. EOF automatically sets these to empty arrays in the super implementation. a) started using EOGenerator Always a good idea. b) updated my EOGenerator templates so that the generated code checks for null in the to-many relationship accessors and returns an empty array if it is null You should not need to do that, you still have a problem to hunt down. Lo and behold, that fixed the problem. It's frustrating to me that there are so many gotchas in the framework that make it break in very basic places and that have never, ever been documented by Apple (to my knowledge), so much to the point that I have come very close to just giving up WebObjects development all together. But I'm feeling a lot better recently thanks to the support of people like yourself and (what seems to be) a helpful growing user community containing people like the project wonder guys. I feel like WebObjects is once again becoming a good useable, viable development platform in spite of Apple's loathsome lack of support for the product, because of a user community that is taking up the slack. Thanks! It does just work _if_ you don't abuse it and follow good OO process (e.g. call super unless you have a damn good reason to not do so). Chuck On Mar 26, 2007, at 12:53 PM, Chuck Hill wrote: On Mar 24, 2007, at 9:37 PM, Steven Mark McCraw wrote: Hi Chuck, That's was a good thought, and actually I was not locking the child EC. It still strikes me as bizarre that the responsibility of locking and unlocking the editing context is left up to the programmer, but that's just me griping. I am not sure what the original rationale for not providing something at the WOSession level to manage more editing contexts. Also, it looks from the output like ERXEC is getting used (although I haven't done anything explicitly other than importing the project wonder frameworks and subclassing ERXApplication and ERXSession). Isn't that supposed to do automatic locking/ unlocking for you, or is there something I need to add? Could ERXEC be part of the problem? I modified my code by adding a nestedEC.lock() before the saveChanges, and a nestedEC.unlock() after, but to no avail. I still got the same behavior. Any other thoughts about what I might be doing wrong? It seems like such a simple thing I'm trying to do... I trust you have seen Mike's message on this. Alternately, is there any workaround other than storing attribute values in local instance variables which are then just copied into the EO itself right before the save is committed? Would it really be such a terrible idea just to not insert the EO into an editing context until you know you're ready to save? A very terrible idea. Unless, of course, you want to spend even more quality debugging time with your app. ;-) I keep reading things that say that this is a terrible idea, but I've actually been doing it for years with no apparent problems. We call that luck. But because of all the posts, etc. that say it's a bad idea, I'm trying to use the nested EC technique, but quite literally 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 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 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 of the documentation. I'm creating a nested editing context: EOEditingContext nestedEC = new EOEditingContext (session.defaultEditingContext); and then creating my EOs in this. When it's time to save, I do the foll
Re: Problem with nested editing contexts
Hi Chuck,
As it turns out, I was abusing EOF (although not in a way that has
ever been documented by Apple, to my knowledge). In my EOModeler
generation template, I was initializing all of the the to-many
relationships to empty (but non-null) arrays in the generated
constructor 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:
a) started using EOGenerator
b) updated my EOGenerator templates so that the generated code checks
for null in the to-many relationship accessors and returns an empty
array if it is null
Lo and behold, that fixed the problem. It's frustrating to me that
there are so many gotchas in the framework that make it break in very
basic places and that have never, ever been documented by Apple (to
my knowledge), so much to the point that I have come very close to
just giving up WebObjects development all together. But I'm feeling
a lot better recently thanks to the support of people like yourself
and (what seems to be) a helpful growing user community containing
people like the project wonder guys. I feel like WebObjects is once
again becoming a good useable, viable development platform in spite
of Apple's loathsome lack of support for the product, because of a
user community that is taking up the slack. Thanks!
Mark
On Mar 26, 2007, at 12:53 PM, Chuck Hill wrote:
On Mar 24, 2007, at 9:37 PM, Steven Mark McCraw wrote:
Hi Chuck,
That's was a good thought, and actually I was not locking the
child EC. It still strikes me as bizarre that the responsibility
of locking and unlocking the editing context is left up to the
programmer, but that's just me griping.
I am not sure what the original rationale for not providing
something at the WOSession level to manage more editing contexts.
Also, it looks from the output like ERXEC is getting used
(although I haven't done anything explicitly other than importing
the project wonder frameworks and subclassing ERXApplication and
ERXSession). Isn't that supposed to do automatic locking/
unlocking for you, or is there something I need to add? Could
ERXEC be part of the problem? I modified my code by adding a
nestedEC.lock() before the saveChanges, and a nestedEC.unlock()
after, but to no avail. I still got the same behavior. Any other
thoughts about what I might be doing wrong? It seems like such a
simple thing I'm trying to do...
I trust you have seen Mike's message on this.
Alternately, is there any workaround other than storing attribute
values in local instance variables which are then just copied into
the EO itself right before the save is committed? Would it really
be such a terrible idea just to not insert the EO into an editing
context until you know you're ready to save?
A very terrible idea. Unless, of course, you want to spend even
more quality debugging time with your app. ;-)
I keep reading things that say that this is a terrible idea, but
I've actually been doing it for years with no apparent problems.
We call that luck.
But because of all the posts, etc. that say it's a bad idea, I'm
trying to use the nested EC technique, but quite literally 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
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 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 of the
documentation. I'm creating a nested editing context:
EOEditingContext nestedEC = new EOEditingContext
(session.defaultEditingContext);
and then creating my EOs in this. When it's time to save, I do
the following:
nestedEC.saveChanges();
session.defaultEditingContext().saveChanges();
This seems to work fine with newly created items. The problem
comes when I try to do that on an item that has been modified.
I have printed out a few things within the code to confirm
this: when the nested editing context saves its changes, it's
supposed to push them into its parent context (or so I thought),
but this is definitely not happening. Is this a well known
issue? Has anyone seen this before? Am I missing something? A
couple of hours of googling turned up nothing for me. The code
and its output is shown below.
Thanks in advance for any help.
NSLog.out.appendln("nestedEC updatedObjects: " +
nestedEC.updatedObject
Re: Strange _EOCheapCopyMutableArray crash
Hi Ian,
On Mar 25, 2007, at 9:43 PM, Ian Joyner wrote:
I'm getting a crash in the following code:
public boolean is_unassigned () {
// editingContext ().refaultObject (this);
log.info ("is_unassigned " + this.groups ());
boolean result = true;
java.util.Enumeration e = groups
().objectEnumerator ();
while (result && e.hasMoreElements ()) {
Group_Member gm = e.nextElement ();
if (gm.group ().parent_group () != null && gm.end_date () ==
null) result = false;
}
return result;
}
caused by groups on line 5 being a _EOCheapCopyMutableArray.
Um, no. That just means it is an unfired array fault. See below for
actual cause.
The enclosing object for this method was originally created in
another editingContext (being Java client, in another window), so I
suspect something to do with the groups being in another (now gone)
editing context. It does not happen all the time though, only on
the first object created - if I restart the application, further
objects can be added without problem.
It could he a Java Client related bug. It also sounds like that can
happen with incorrect locking of editing contexts or general EOF
abuse. I seem to be saying that a lot lately... :-) Something has
messed up the object graph and / or the local EC representation.
A fix that seems to work is the commented out line 'editingContext
().refaultObject (this);', but this seems to me like it is probably
a kludge making up for a problem elsewhere. Anything else I should
be looking out for?
I agree, this is just hiding or recovering from a problem elsewhere.
com.webobjects.eocontrol._EOCheapCopyMutableArray[b7ecdb]
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at
com.webobjects.eodistribution.client.EODistributedObjectStore.objectsF
orSourceGlobalID(EODistributedObjectStore.java:338)
That is where the problem happens, it is a NPE not a class cast
exception.
...
Here is the problem:
Exception in thread "AWT-EventQueue-0"
java.lang.IllegalStateException: objectsForSourceGlobalID:
com.webobjects.eodistribution.client.EODistributedObjectStore
[EMAIL PROTECTED] -
- for object with global ID _EOIntegralKeyGlobalID[Member
(java.lang.Integer)3] -could not find any snapshot.
at
com.webobjects.eodistribution.client.EODistributedObjectStore.objectsF
orSourceGlobalID(EODistributedObjectStore.java:306)
It looks like the snapshot has not been saved or has been discarded.
Is Member #3 a recently created object?
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to archive@mail-archive.com
Re: Problem with nested editing contexts
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 problem out of your app. Isolate it into a small test case woa that just does this test and see if it works or not. If it works, you know you're doing something wrong. If it doesn't, you have a good test case to submit to the wonder list to look at further. ms ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
Re: Problem with nested editing contexts
On Mar 24, 2007, at 9:37 PM, Steven Mark McCraw wrote:
Hi Chuck,
That's was a good thought, and actually I was not locking the child
EC. It still strikes me as bizarre that the responsibility of
locking and unlocking the editing context is left up to the
programmer, but that's just me griping.
I am not sure what the original rationale for not providing something
at the WOSession level to manage more editing contexts.
Also, it looks from the output like ERXEC is getting used (although
I haven't done anything explicitly other than importing the project
wonder frameworks and subclassing ERXApplication and ERXSession).
Isn't that supposed to do automatic locking/unlocking for you, or
is there something I need to add? Could ERXEC be part of the
problem? I modified my code by adding a nestedEC.lock() before the
saveChanges, and a nestedEC.unlock() after, but to no avail. I
still got the same behavior. Any other thoughts about what I might
be doing wrong? It seems like such a simple thing I'm trying to do...
I trust you have seen Mike's message on this.
Alternately, is there any workaround other than storing attribute
values in local instance variables which are then just copied into
the EO itself right before the save is committed? Would it really
be such a terrible idea just to not insert the EO into an editing
context until you know you're ready to save?
A very terrible idea. Unless, of course, you want to spend even more
quality debugging time with your app. ;-)
I keep reading things that say that this is a terrible idea, but
I've actually been doing it for years with no apparent problems.
We call that luck.
But because of all the posts, etc. that say it's a bad idea, I'm
trying to use the nested EC technique, but quite literally 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 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 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 of the
documentation. I'm creating a nested editing context:
EOEditingContext nestedEC = new EOEditingContext
(session.defaultEditingContext);
and then creating my EOs in this. When it's time to save, I do
the following:
nestedEC.saveChanges();
session.defaultEditingContext().saveChanges();
This seems to work fine with newly created items. The problem
comes when I try to do that on an item that has been modified. I
have printed out a few things within the code to confirm this:
when the nested editing context saves its changes, it's supposed
to push them into its parent context (or so I thought), but this
is definitely not happening. Is this a well known issue? Has
anyone seen this before? Am I missing something? A couple of
hours of googling turned up nothing for me. The code and its
output is shown below.
Thanks in advance for any help.
NSLog.out.appendln("nestedEC updatedObjects: " +
nestedEC.updatedObjects());
NSLog.out.appendln("nestedEC.parent: " +
nestedEC.parentObjectStore());
NSLog.out.appendln("session.defaultEditingContext: " +
session.defaultEditingContext());
nestedEC.saveChanges();
NSLog.out.appendln("session.defaultEditingContext
updatedObjects: " + session.defaultEditingContext
().updatedObjects());
session.defaultEditingContext().saveChanges();
The output is:
nestedEC updatedObjects: (Test, 380.00, null)
nestedEC.parent: [EMAIL PROTECTED]
session.defaultEditingContext: [EMAIL PROTECTED]
session.defaultEditingContext updatedObjects: ()
The first line shows that there is an updated object in the
nested EC
The second and third lines show that the ec is actually nested
within another
editing context and that the nested ec's parent is the session's
default editingContext
The fourth line shows that after calling saveChanges() in the
nested ec, the parent ec still is showing no objects to update
Consequently, if I check the database after calling the final
saveChanges, my change is not there.
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/chill%
40global-village.net
This email sent to [EMAIL PROTECTED]
--
Practical WebObjects - for developers who want to increase their
overall knowled
Re: Designing Batch List entries
On Mar 23, 2007, at 12:53 PM, Ted Archibald wrote: Hi, I'm developing a series of internal applications that focus on bookkeeping and accounting. Using webobjects how would one one design a simple app for batch entries similar to what one would do in Excel? These entries could be anywhere from 5 per batch up to 200 per batch. Data entry could be as simple as: Account, Amount A-1, $10.20 A-23, $23.54 X-40 $17.25 etc. Let's say we have an EO called Payment that consists of a PK, Account Name and a Dollar Amount, First off, that should almost certainly be accountFK. Let the user enter the account name, but look it up the Acounts and make it a proper relationship in the EO. then another EO that contains multiples of the previous. From my testing, if you created 200-500 empty Payment EOs, the app takes a substantial amount of time to set each object up in memory. How do you define "a substantial amount of time"? It should be very fast to create those objects. Even saving 500 small objects should be fast, though some databases are faster than others. Partly this depends (as I recently found out from Mike) on how the JDBC adaptor for that database implements requests for multiple new primary keys for an entity. If it is actually taking significant time then you are probably doing something wrong. I've also played with creating a number of WOTextFields tied to an array of 200-500 strings (instead of directly to an EO). The problem I'm encountering is that this seems terribly inefficient, slow and very non-webobjects. I see no reason to do that. You could probably do it fairly efficiently with POJO Payment objects that translate themselves into Payment EOs, but I don't see a compelling reason to do that here. Ultimately my goals are: fast entry, validation on the entry, account information lookup etc. Ajax might be of use here, it could be doing the account name lookup/ validation while the user was entering more data. Chuck -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
