• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Direct to Web, Refresh change_stamp column
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Direct to Web, Refresh change_stamp column


  • Subject: Re: Direct to Web, Refresh change_stamp column
  • From: Justin Tocci <email@hidden>
  • Date: Fri, 20 Aug 2004 15:03:25 -0500

Yeah. I set each table up with the padlock on the change_stamp and the primary key. It is my understanding that this way only these items are compared to the database to confirm that the record has not changed. This is quicker than checking a lot of long text fields for changes (which I have in about half my tables).

I am in the process of removing the change_stamps because I am setting up log tables that archive all old records. If performance isn't an issue I may get rid of them all. My problem is still there however, because if a Microsoft Access user changes some record that the web user then wanted to change it would prevent them from doing it until WebObjects decides to refetch on its own

Having looked into this most of the day, I found a Jonathan that posted that, for this problem with fetchspecs I need to do two things:

1)  In your Application constructor, call:
EOEditingContext.setDefaultFetchTimestampLag(0);

2) Every time you create an EOFetchSpecification, call
setRefreshesRefetchedObjects(true) on it.

I am now looking to see if it works to use these bits with Direct to Web. Any advice appreciated. Thanks all.

justin


On Aug 20, 2004, at 2:37 PM, Hunter Hillegas wrote:

My guess is that the change_stamp column is included in the locking (padlock in EOModeler), which means it is included in the WHERE clause for updates.

On Aug 20, 2004, at 11:45 AM, Justin Tocci wrote:

Hi all. I've got a many-to-many table relationship in postgres working with several Direct to Web generated pages that I'm going to put into an application. My problem is that I have a change_stamp column in all my tables that is updated by a TRIGGER in postgresl.

So if anyone changes any data in a given record, the change_stamp column in that record gets a new date and time automatically.

Problem is my model isn't aware of this. I make a change, it commits the change (but doesn't realize the change_stamp column has changed) and when I go to make another change to the same record I get:

Could not save your changes:
updateValuesInRowDescribedByQualifier -- com.webobjects.jdbcadaptor.JDBCChannel method failed to update row in database


Which wouldn't be the end of the world except it still doesn't do a refresh and there is no refresh button in the Direct to Web pages that I am aware of.

Am I missing a checkbox or setting somewhere that will fix this? I've got non-WebObjects applications that change data and that will likely cause the same problem, so I need it to re-fetch the data after every commit, and whenever the above error occurs.

Any hints greatly appreciated.



justin tocci
fort wayne, in
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.


References: 
 >Direct to Web, Refresh change_stamp column (From: Justin Tocci <email@hidden>)

  • Prev by Date: Direct to Web, Refresh change_stamp column
  • Next by Date: Re: XCode project index invalid
  • Previous by thread: Direct to Web, Refresh change_stamp column
  • Next by thread: eomodeler, ldap, and many-to-many relationships
  • Index(es):
    • Date
    • Thread