• 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: BigDecimal, scale, and prototypes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BigDecimal, scale, and prototypes


  • Subject: Re: BigDecimal, scale, and prototypes
  • From: Chuck Hill <email@hidden>
  • Date: Fri, 15 Aug 2008 11:29:28 -0700


On Aug 15, 2008, at 11:15 AM, Florijan Stamenkovic wrote:


On Aug 15, 2008, at 11:45, T Worman wrote:

Florijan:

I have found that setting the scale in the model did not result in properly setting the scale of the attributes in my EO's. I am using OpenBase. There could be a number of reasons for this and I didn't investigate real hard.

The scale of attributes in Java *should* directly reflect the scale set in the database, due to the way BigDecimal's constructors work, even if EOF does not intervene.


Wanting to be sure what is happening, I just made a test application (WO5.3, FrontBase, 10.4.11, wonder currencyAmount prototype). In short, the database respects the scale of the model. Java respects the scale too. The scale of fetched BigDecimals is fixed, if not all of it is used they are zero padded. Who exactly is responsible for this I am not sure, but it is a pleasantly consistent behavior.

EOF sets the scale when the values are fetched.

As for the input of BigDecimals that have a scale greater then what is allowed are rounded (HALF_UP), no exceptions raised. This is a bit mysterious. From what you guys are saying, it could be concluded that EOF does not deal with this. If that is so, then it also does not raise an exception when there is more digits then the model allows. This does not sound OK, on it's part. If EOF does deal with this (coercion), Dave should not have received an exception on the db level, and things should have worked fine for Timothy. Uhm, weird.

I don't exactly recall where I ran into problems. I _think_ it might have been setting a default value in awakeFromInsertion() with a scale that did not match the model. The save succeeded, but the scale in the snapshot did not match data fetched from the database so that updates of that object failed until the snapshot was refreshed. But I might just be imagining that. I use them a lot, I rarely have problems and the problems are always my fault.



Chuck


What I did was override the getters for those attributes in the java classes.

Yeah, I was thinking of doing that, but we might be handling high volumes of this kind of data, the less extra BigDecimal operations I do, the better.


Thanks,
F


--
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 (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: BigDecimal, scale, and prototypes
      • From: Mike Schrag <email@hidden>
References: 
 >BigDecimal, scale, and prototypes (From: Florijan Stamenkovic <email@hidden>)
 >Re: BigDecimal, scale, and prototypes (From: T Worman <email@hidden>)
 >Re: BigDecimal, scale, and prototypes (From: Florijan Stamenkovic <email@hidden>)

  • Prev by Date: Re: BigDecimal, scale, and prototypes
  • Next by Date: Re: BigDecimal, scale, and prototypes
  • Previous by thread: Re: BigDecimal, scale, and prototypes
  • Next by thread: Re: BigDecimal, scale, and prototypes
  • Index(es):
    • Date
    • Thread