• 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: ?? about opportunistic locking...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ?? about opportunistic locking...


  • Subject: Re: ?? about opportunistic locking...
  • From: Miguel Arroz <email@hidden>
  • Date: Tue, 18 May 2010 15:16:31 +0100

Hi!

On 2010/05/18, at 14:07, Miguel Arroz wrote:

>  And, BTW, another detail for the most curious readers...
>
>>> Application.Application: C1 1274149686265
>>> Application.Application: C2 1274149686265
>
>  If this attribute was an integer or long (with the timestamp, for instance) and not a string, in this specific situation, the second commit would not produce any SQL statement. Why? :)

  Fix: it doesn't matter if it's a string, it only matters if those two values are equal(). Here, they aren't (C1 and C2 are part of the value). But if they did...

  Never post before tea.

  Yours

Miguel Arroz

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: ?? about opportunistic locking...
      • From: David Avendasora <email@hidden>
References: 
 >?? about opportunistic locking... (From: Theodore Petrosky <email@hidden>)
 >Re: ?? about opportunistic locking... (From: Mark Ritchie <email@hidden>)
 >Re: ?? about opportunistic locking... (From: Mike Schrag <email@hidden>)
 >Re: ?? about opportunistic locking... (From: Mark Ritchie <email@hidden>)
 >Re: ?? about opportunistic locking... (From: Miguel Arroz <email@hidden>)

  • Prev by Date: Re: ?? about opportunistic locking...
  • Next by Date: Re: ?? about opportunistic locking...
  • Previous by thread: Re: ?? about opportunistic locking...
  • Next by thread: Re: ?? about opportunistic locking...
  • Index(es):
    • Date
    • Thread