• 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: Optimistic locking failure due to string trimming?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Optimistic locking failure due to string trimming?


  • Subject: Re: Optimistic locking failure due to string trimming?
  • From: Chuck Hill <email@hidden>
  • Date: Thu, 24 Jun 2010 09:29:58 -0700

On Jun 24, 2010, at 3:18 AM, Paul Hoadley wrote:

> Hello,
>
> Today I ran into the following problem:
>
> 1.  I have an entity with a 'note' attribute which uses the 'longText' prototype from (PostgreSQL) ERPrototypes.  'longText' has external type VARCHAR, and data type 'String (RTRIM) - String c'.  'note' is an attribute used for locking.

Is there a chance that it just the wrong data type?  IIRC, this was added for (I think) Oracle which automatically did this trimming at the database level.  If EOF did not also do it, trailing spaces caused this problem.


> 2.  A user has apparently entered some text into the 'note' attribute of an EO with a trailing space.  The trailing space made it to the database.  Just by a stroke of luck, I managed to see it while nosing around with psql.  (If I hadn't, I imagine I'd still be scratching my head.)
>
> 3.  The WHERE clause generated at update time checks for that string _without a trailing space_.
>
> 4.  An optimistic locking failure ensues.
>
> Is this expected?  What does the 'RTRIM' in that data type mean—that is, _when_ is there trimming?  I take it there's no trimming for an INSERT, or that trailing space wouldn't have made it out to the database.  As a workaround, I was going to unselect 'note' as an attribute used for locking.


Sounds like a sketchy implementation, but if the database trims on insert/update, EOF would only need to do this for the WHERE clause.  Which is what you are seeing.  As the database is obviously NOT doing this trim, I will gently suggest that the prototype has the incorrect data type.


Chuck

--
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







Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Optimistic locking failure due to string trimming?
      • From: Paul Hoadley <email@hidden>
References: 
 >Optimistic locking failure due to string trimming? (From: Paul Hoadley <email@hidden>)

  • Prev by Date: [MEET] Toronto Cocoaheads / tacow - July 6
  • Next by Date: Re: fetchspec problem
  • Previous by thread: Optimistic locking failure due to string trimming?
  • Next by thread: Re: Optimistic locking failure due to string trimming?
  • Index(es):
    • Date
    • Thread