Re: WOLips Entity Modeler SQL Generation and WO 5.4
Re: WOLips Entity Modeler SQL Generation and WO 5.4
- Subject: Re: WOLips Entity Modeler SQL Generation and WO 5.4
- From: Johann Werner <email@hidden>
- Date: Wed, 8 Jul 2009 09:21:15 +0200
Hi Dave,
this addition to _Entity.java seems very useful. Perhaps it should be
added to the standard templates? They would become more sort of "use
them and don't care" so perhaps file a jira.
jw
Am 08.07.2009 um 01:00 schrieb David Avendasora:
On Jul 7, 2009, at 6:17 PM, Miguel Angel Torres Avila wrote:
Hi, Thanks for the hint about using Prototypes, it is really useful.
That brought to my mine a questing that is a little out of the topic.
If you have an attribute prototyped as currencyAmount the precision
is set to 38 and the scale to 4. The Data Type suggested is
java.math.BigDecimal.
How are you guys controlling that the BigDecimal in your java class
does not have a value whit a scale superior of 4 before saving the
editing context to avoid an exception?
We are currently solving this just rounding the value before
saving, or in the validation method to ensure the scale is not
superior that the value defined in modeler. But one of the great
things of prototyping is that if for some reason I want to change
the scale to 5 instead 4, all the attribute definition's that are
using that prototype will be updated, what about the BigDecimal?
Maybe I am wrong on thinking that I should be sure that the scale
of my BigDecimal must be less than or equals to the scale defined
in the modeler to avoid exception on saving.
How do you guys handle this?
I have modified my EOGenerator _Entity.java template to watch for
BigDecimal data types and to automatically set the scale to what the
Model has the scale set to. Here's the snippit of code from the
attribute setter method:
#if ($attribute.javaClassName == "java.math.BigDecimal")
if (${attribute.name} != null) {
${attribute.name} = ${attribute.name}.setScale($
{attribute.scale}, RoundingMode.HALF_UP);
}
#end
I never had an error since I started using this and if I change the
settings in the EOModel, my classes are updated when the
EOGeneration runs.
Dave
On Jul 7, 2009, at 2:42 PM, Johann Werner wrote:
Am 07.07.2009 um 21:09 schrieb Scott M. Neal:
On Jun 30, 2009, at 5:43 PM, David Avendasora wrote:
On Jun 30, 2009, at 8:29 PM, Scott M. Neal wrote:
Well, if you're looking for excuses to "upgrade" things, maybe
transition to using Prototypes. I'm sure the Postgress
Prototypes in Wonder's ERPrototypes will all have the proper
External Types. :-)
Wow, thank you Dave, that DOES make things substantially easier
(and less prone to error--sure enough, had a missing external
type in
one of the entities). All this modern fanciness, still getting
used
to it...
Now my question is, for the Postgresql prototypes, which one
is recommended to use for primary keys? Googling reveals some
people
using long (called longNumber in prototypes), which is what I
historically
used, while others are using varchar (but not consistent
regarding size:
10? 100? 10,000,000? :-))
Why don't you just choose the most obvious prototype: 'id'? Life
can be so easy ;-)
jw
Thank you,
Scott
Otherwise, you should be able to just select one entity at a
time and click the SQL button and see which one(s) generate the
error. I see pretty clear error messages with this, that say
exactly what external type is not recognized.
Dave
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
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
_______________________________
Ing. Miguel Angel Torres Avila
Director General
Tel: +52 (33) 3367 1892
Cel: +52 (33) 3106 8758
E-mail: email@hidden
www.toracom.net
_______________________________________________
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
_______________________________________________
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
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