Re: Get rid of warning in binding value e.g. @sum.totalCost
It's just a hint for the component binding validator to tell it that even though it can't validate that binding, that you _know_ it's correct. As far as other hints, I'm really hoping for the eventual implementation of //DoWhatIWantNotWhatICoded hint that will resolve 90% of my bugs. Dave I browse through the preferences and thought i understand some and some need to try it out... One i still could not figure out is where on earth is the magic word //VALID comes from :) Next level of curiosity is - are there any more. Thanks for d pointers. - Original Message - From: Kieran Kelleher To: Cheong Hee Ng Cc: Dawn Lockhart ; webobjects-dev@lists.apple.com Sent: Thursday, May 20, 2010 1:04 AM Subject: Re: Get rid of warning in binding value e.g. @sum.totalCost By the way, u probably know already, but you can edit wolips preferences to get rid of some/many of the warnings On May 19, 2010, at 12:11 PM, Cheong Hee Ng wrote: No worry, appreciate the info otherwise will still need to live with warning signs. Good day! On Wed, May 19, 2010 at 10:51 PM, Kieran Kelleher kieran_li...@mac.com wrote: Cheong, Yeah, sorry -typo - I should have said//VALID -Kieran On May 19, 2010, at 1:15 AM, Cheong Hee wrote: Make sense, thanks. Probably the first trial was using the backslashes. Sometimes I thought forward slashes and back slashes are really a joke to the users. At one time it is interchangeable, whilst at other moment it is forbidden. grumble / - Original Message - From: Dawn Lockhart dlockh...@k12.com To: chn...@gmail.com Cc: webobjects-dev@lists.apple.com Sent: Tuesday, May 18, 2010 9:19 PM Subject: Re: Webobjects-dev Digest, Vol 7, Issue 304 You have forward slashes instead of backslashes. Try: //VALID ___ 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/kieran_lists%40mac.com This email sent to kieran_li...@mac.com ___ 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/webobjects%40avendasora.com This email sent to webobje...@avendasora.com ___ 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 arch...@mail-archive.com
Re: Invalidating Objects
Hi, this sounds familiar. We have severe problems with vanishing snapshots, but only on one installation. Unfortunately, we found no way to reproduce this on our testing systems. There was a thread about this a while ago, but no real solution: http://lists.apple.com/archives/Webobjects-dev/2010/Mar/msg00330.html Otherwise, what you describe is exactly what we are seeing. We also use invalidate...(), the nulled out EO is never refetched, the only way to recover is to restart the app. Well, if you would be able to reproduce this in a small defined scenario, that would be extremely helpful. Marc On 18.05.2010, at 23:24, Andrew Lindesay wrote: Hello; As part of a built-in change notification facility, I am using EOObjectStoreCoordinator.invalidateObjectsWithGlobalIDs(..) with the relevant OSC locked. All use of other editing contexts are locked and unlocked correctly. Occasionally I seem to end up with disappearing snapshots where all the values of the snapshot go to NULL -- I can only imagine this would be linked to my use of 'invalidate..'. Other new editing contexts then see the NULLed-out EO and the EO does not seem to re-fault in that instance. When that corrupted EO is used in some sort of qualifier, EOF will treat the primary-key qualifier as looking for NULL. Any ideas where to look or has anybody else had this problem and has any pointers? cheers. ___ Andrew Lindesay www.silvereye.co.nz ___ 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/yoda%40schli.ch This email sent to y...@schli.ch ___ 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 arch...@mail-archive.com
Re: Invalidating Objects
On May 18, 2010, at 5:24 PM, Andrew Lindesay wrote: Hello; As part of a built-in change notification facility, I am using EOObjectStoreCoordinator.invalidateObjectsWithGlobalIDs(..) with the relevant OSC locked. All use of other editing contexts are locked and unlocked correctly. Occasionally I seem to end up with disappearing snapshots where all the values of the snapshot go to NULL -- I can only imagine this would be linked to my use of 'invalidate..'. Other new editing contexts then see the NULLed-out EO and the EO does not seem to re-fault in that instance. When that corrupted EO is used in some sort of qualifier, EOF will treat the primary-key qualifier as looking for NULL. Any ideas where to look or has anybody else had this problem and has any pointers? cheers. ___ Andrew Lindesay www.silvereye.co.nz Hi Andrew! I've seen similar problems, but I don't think it was related to invalidating objects. It appeared related to the use of nested editing contexts. There was a discussion about it around two months ago... http://www.mail-archive.com/webobjects-dev@lists.apple.com/msg36101.html Using a nested editing context anywhere? Ramsey ___ 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 arch...@mail-archive.com
Re: Invalidating Objects
Hello Ramsey Marc Thanks for getting back to me. I've seen similar problems...Using a nested editing context anywhere? I _was_ until they seemed to causing some other problems so I have removed use of that now. I don't think the nested ECs would have been used on the instances where the problem was manifesting itself though. Otherwise, what you describe is exactly what we are seeing. We also use invalidate...(), the nulled out EO is never refetched, the only way to recover is to restart the app. What I have done is to use a lock across the work of handling R-R cycles and the change notification (the only place where the invalidate is actioned). In this way, if the issue is one of concurrency with regular EC use then I should see this issue go away for human-facing instances which are doing any EC-work outside of the R-R cycles. It's still a fair way off a production deploy, but I will let you know if this resolves the issue. cheers. ___ Andrew Lindesay www.silvereye.co.nz ___ 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 arch...@mail-archive.com
Re: Invalidating Objects
What I have done is to use a lock across the work of handling R-R cycles and the change notification (the only place where the invalidate is actioned). In this way, if the issue is one of concurrency with regular EC use then I should see this issue go away for human-facing instances which are doing any EC-work outside of the R-R cycles. It's still a fair way off a production deploy, but I will let you know if this resolves the issue. in wonder's we take a dbc lock during the background queue processing, then do a refreshing fetch of the affected EO so that it updated the snapshots. you really don't want to ever do an .invalidate() because if you any EO's in an modified state, they'll be messed up. 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 arch...@mail-archive.com
Re: Invalidating Objects
Hello Mike; I think I was _just_ doing fetches at one point, but I suspect that there was a change in 5.3 - 5.4 in that invalidate...() in 5.3 did not drop to-manys from caches in EOF and 5.4 seemed to. In 5.3 fresh fetch with pre-pretches into to-manys did re-cache the to-many, but in 5.4 it did not seem to. I obviously am unable to look and see what it is actually doing, but that is my observation and the only way I could get it to function for to-many's is to use invalidate... –– I presume that change notification in PW is functioning seamlessly under high load in 5.4 without invalidate and for to-many relationships? Do you take out a DBC lock for the duration of the change notification process for all DBC's which are involved in the changes? I guess I should go take a look... cheers. What I have done is to use a lock across the work of handling R-R cycles and the change notification (the only place where the invalidate is actioned). In this way, if the issue is one of concurrency with regular EC use then I should see this issue go away for human-facing instances which are doing any EC-work outside of the R-R cycles. It's still a fair way off a production deploy, but I will let you know if this resolves the issue. in wonder's we take a dbc lock during the background queue processing, then do a refreshing fetch of the affected EO so that it updated the snapshots. you really don't want to ever do an .invalidate() because if you any EO's in an modified state, they'll be messed up. ___ Andrew Lindesay www.silvereye.co.nz ___ 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 arch...@mail-archive.com
Re: Invalidating Objects
Does this have any bearing on your problem?
/**
* Clears snapshot the relaationship of a given enterprise so it
will be read again when next accessed.
* @param eo enterprise object
* @param relationshipName relationship name
*/
public static void
clearSnapshotForRelationshipNamed(EOEnterpriseObject eo, String
relationshipName) {
EOEditingContext ec = eo.editingContext();
EOModel model = EOUtilities.entityForObject(ec, eo).model();
EOGlobalID gid = ec.globalIDForObject(eo);
EODatabaseContext dbc =
EODatabaseContext.registeredDatabaseContextForModel(model, ec);
EODatabase database = dbc.database();
ERXEOControlUtilities.clearSnapshotForRelationshipNamedInDatabase(eo,
relationshipName, database);
}
That is what I use to re-fresh to-many relationships. The only time I
use invalidate is when I know that an EO with a snapshot has been
deleted from the database.
Chuck
On May 20, 2010, at 3:53 PM, Andrew Lindesay wrote:
Hello Mike;
I think I was _just_ doing fetches at one point, but I suspect that
there was a change in 5.3 - 5.4 in that invalidate...() in 5.3
did not drop to-manys from caches in EOF and 5.4 seemed to. In 5.3
fresh fetch with pre-pretches into to-manys did re-cache the to-
many, but in 5.4 it did not seem to. I obviously am unable to look
and see what it is actually doing, but that is my observation and
the only way I could get it to function for to-many's is to use
invalidate... –– I presume that change notification in PW is
functioning seamlessly under high load in 5.4 without invalidate and
for to-many relationships? Do you take out a DBC lock for the
duration of the change notification process for all DBC's which are
involved in the changes? I guess I should go take a look...
cheers.
What I have done is to use a lock across the work of handling R-R
cycles and the change notification (the only place where the
invalidate is actioned). In this way, if the issue is one of
concurrency with regular EC use then I should see this issue go
away for human-facing instances which are doing any EC-work
outside of the R-R cycles. It's still a fair way off a production
deploy, but I will let you know if this resolves the issue.
in wonder's we take a dbc lock during the background queue
processing, then do a refreshing fetch of the affected EO so that
it updated the snapshots. you really don't want to ever do
an .invalidate() because if you any EO's in an modified state,
they'll be messed up.
___
Andrew Lindesay
www.silvereye.co.nz
___
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 ch...@global-village.net
--
Chuck Hill Senior Consultant / VP Development
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 arch...@mail-archive.com
RE: Invalidating Objects
Hi Chuck; That looks perfect thanks; I will try it out soon! cheers. Does this have any bearing on your problem? ... That is what I use to re-fresh to-many relationships. The only time I use invalidate is when I know that an EO with a snapshot has been deleted from the database. ___ Andrew Lindesay www.silvereye.co.nz ___ 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 arch...@mail-archive.com
