arrgghh

[rstudner]

Okay.. so somehow i have multiple deployed grails apps (1.0 =-> 1.2)

so I'm making a new one with 1.3.1..

I do

package com.xyz.model;


class ZipCode {

  String zip
  String state
 
  static constraints = {
  }
}

I fire up grails console or grails shell

first I do:

new ZipCode(zip:'12345').save()

tells me ZipCode can't be found.. okay

I do new com.xyz.model.ZipCode(zip:'12345').save()

and I get back null.

I mean, really?  default hsqldb dev/test/prod db setup..

what the heck is going on  :)?

Roger




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[burtbeckwith]

Properties are not-null by default, so since you're missing a value for state it's not valid.

Burt

> Okay.. so somehow i have multiple deployed grails apps (1.0 =-> 1.2)
>
> so I'm making a new one with 1.3.1..
>
> I do
>
> package com.xyz.model;
>
>
> class ZipCode {
>
>   String zip
>   String state
>  
>   static constraints = {
>   }
> }
>
> I fire up grails console or grails shell
>
> first I do:
>
> new ZipCode(zip:'12345').save()
>
> tells me ZipCode can't be found.. okay
>
> I do new com.xyz.model.ZipCode(zip:'12345').save()
>
> and I get back null.
>
> I mean, really?  default hsqldb dev/test/prod db setup..
>
> what the heck is going on  :)?
>
> Roger
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Mike Cantrell-2]

Constraints are not-null by default. You need to specify a state. If you'd like proactive validation errors, enable them via configuration:

http://grails.org/doc/1.2.x/guide/3.%20Configuration.html#3.1.3%20GORM
http://grails.org/doc/1.2.x/ref/Constraints/Usage.html

On Tue, Jun 15, 2010 at 9:31 PM, Roger Studner <[hidden email]> wrote:

Okay.. so somehow i have multiple deployed grails apps (1.0 =-> 1.2)

so I'm making a new one with 1.3.1..

I do

package com.xyz.model;


class ZipCode {

 String zip
 String state

 static constraints = {
 }
}

I fire up grails console or grails shell

first I do:

new ZipCode(zip:'12345').save()

tells me ZipCode can't be found.. okay

I do new com.xyz.model.ZipCode(zip:'12345').save()

and I get back null.

I mean, really?  default hsqldb dev/test/prod db setup..

what the heck is going on  :)?

Roger




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[rstudner]

Thanks Mike and Burt

I dug through my old code.. which was chaulk full of defaults and good constraints.

I guess I fell into the "demo trap" of Book's and Authors... where there is so little data, and no constraints.. and just forgot

appreciate the wake up call heh

Roger

On Jun 15, 2010, at 11:05 PM, Mike Cantrell wrote:

Constraints are not-null by default. You need to specify a state. If you'd like proactive validation errors, enable them via configuration:

http://grails.org/doc/1.2.x/guide/3.%20Configuration.html#3.1.3%20GORM
http://grails.org/doc/1.2.x/ref/Constraints/Usage.html

On Tue, Jun 15, 2010 at 9:31 PM, Roger Studner <[hidden email]> wrote:

Okay.. so somehow i have multiple deployed grails apps (1.0 =-> 1.2)

so I'm making a new one with 1.3.1..

I do

package com.xyz.model;


class ZipCode {

 String zip
 String state

 static constraints = {
 }
}

I fire up grails console or grails shell

first I do:

new ZipCode(zip:'12345').save()

tells me ZipCode can't be found.. okay

I do new com.xyz.model.ZipCode(zip:'12345').save()

and I get back null.

I mean, really?  default hsqldb dev/test/prod db setup..

what the heck is going on  :)?

Roger




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Mike Cantrell-2]

No problem, I feel your pain. The ability to raise exceptions upon validation error was added in 1.2 but it's still not the default. I can't imagine many circumstances where you'd rather explicit check for validation errors. It's just a personal opinion but I think it's silly that it's not the default.

On Tue, Jun 15, 2010 at 10:08 PM, Roger Studner <[hidden email]> wrote:

Thanks Mike and Burt

I dug through my old code.. which was chaulk full of defaults and good constraints.

I guess I fell into the "demo trap" of Book's and Authors... where there is so little data, and no constraints.. and just forgot

appreciate the wake up call heh

Roger

On Jun 15, 2010, at 11:05 PM, Mike Cantrell wrote:

Constraints are not-null by default. You need to specify a state. If you'd like proactive validation errors, enable them via configuration:

http://grails.org/doc/1.2.x/guide/3.%20Configuration.html#3.1.3%20GORM
http://grails.org/doc/1.2.x/ref/Constraints/Usage.html

On Tue, Jun 15, 2010 at 9:31 PM, Roger Studner <[hidden email]> wrote:

Okay.. so somehow i have multiple deployed grails apps (1.0 =-> 1.2)

so I'm making a new one with 1.3.1..

I do

package com.xyz.model;


class ZipCode {

 String zip
 String state

 static constraints = {
 }
}

I fire up grails console or grails shell

first I do:

new ZipCode(zip:'12345').save()

tells me ZipCode can't be found.. okay

I do new com.xyz.model.ZipCode(zip:'12345').save()

and I get back null.

I mean, really?  default hsqldb dev/test/prod db setup..

what the heck is going on  :)?

Roger




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[ccllc]

If the overhead for exceptions is moot within Grails, it may be a simple
matter of choice between exceptions and explicit error checking.
Originally (circa 2000) exceptions seemed like the best way to deal with
signaling the system that there were validation and other kinds of
problems, but it seemed like Sun wanted those perfectly good signals to
remain error-related.

And now Grails' (Spring's?) taste for implicit exceptions addresses how
much programmers were annoyed with checked exceptions, right?

OTOH from my experience validation exceptions only work as a final signal
from a complex validation system when you're working with a website and
any semi-complex object model.  While Grails does more aggregating of
validation errors than most other Java web frameworks (yay!), Grails is
stunted by the lack of consistently inheriting or referencing constraints
thereby requiring copy-and-pasted code for command objects or most any
other rules sharing.

But Grails is a good step forward in modernizing Java validation.

> No problem, I feel your pain. The ability to raise exceptions upon
> validation error was added in 1.2 but it's still not the default. I can't
> imagine many circumstances where you'd rather explicit check for
> validation
> errors. It's just a personal opinion but I think it's silly that it's not
> the default.
>
> On Tue, Jun 15, 2010 at 10:08 PM, Roger Studner <[hidden email]>
> wrote:
>
>> Thanks Mike and Burt
>>
>> I dug through my old code.. which was chaulk full of defaults and good
>> constraints.
>>
>> I guess I fell into the "demo trap" of Book's and Authors... where there
>> is
>> so little data, and no constraints.. and just forgot
>>
>> appreciate the wake up call heh
>>
>> Roger
>>
>> On Jun 15, 2010, at 11:05 PM, Mike Cantrell wrote:
>>
>> Constraints are not-null by default. You need to specify a state. If
>> you'd
>> like proactive validation errors, enable them via configuration:
>>
>> http://grails.org/doc/1.2.x/guide/3.%20Configuration.html#3.1.3%20GORM
>> http://grails.org/doc/1.2.x/ref/Constraints/Usage.html
>>
>>
>> On Tue, Jun 15, 2010 at 9:31 PM, Roger Studner <[hidden email]>
>> wrote:
>>
>>> Okay.. so somehow i have multiple deployed grails apps (1.0 =-> 1.2)
>>>
>>> so I'm making a new one with 1.3.1..
>>>
>>> I do
>>>
>>> package com.xyz.model;
>>>
>>>
>>> class ZipCode {
>>>
>>>  String zip
>>>  String state
>>>
>>>  static constraints = {
>>>  }
>>> }
>>>
>>> I fire up grails console or grails shell
>>>
>>> first I do:
>>>
>>> new ZipCode(zip:'12345').save()
>>>
>>> tells me ZipCode can't be found.. okay
>>>
>>> I do new com.xyz.model.ZipCode(zip:'12345').save()
>>>
>>> and I get back null.
>>>
>>> I mean, really?  default hsqldb dev/test/prod db setup..
>>>
>>> what the heck is going on  :)?
>>>
>>> Roger
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[pledbrook]

> No problem, I feel your pain. The ability to raise exceptions upon
> validation error was added in 1.2 but it's still not the default. I can't
> imagine many circumstances where you'd rather explicit check for validation
> errors. It's just a personal opinion but I think it's silly that it's not
> the default.

Surely any case in which you accept user input? You certainly don't
want exceptions propagating to the user simply because of some
constraint violations. In the bootstrap and the console, it makes more
sense to throw an exception.

Anyway, I'm not going to argue which is the more sensible default but
I will say this is very unlikely to change since we've had this
behaviour for a few years and people would probably get upset if we
changed it :)

Peter

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[pledbrook]

> OTOH from my experience validation exceptions only work as a final signal
> from a complex validation system when you're working with a website and
> any semi-complex object model.  While Grails does more aggregating of
> validation errors than most other Java web frameworks (yay!), Grails is
> stunted by the lack of consistently inheriting or referencing constraints
> thereby requiring copy-and-pasted code for command objects or most any
> other rules sharing.

You do know that you can now specify default constraints that apply to
all domain classes and named ones that you can explicitly reference
from your constraints blocks?

    grails.gorm.default.constraints = {
        '*'(nullable:true, blank:false, size:1..20)
    }

and

    grails.gorm.default.constraints = {
        myConstraints(nullable:true, blank:false, size:1..20)
    }

    static constraints = {
        myProperty shared:"myConstraints"
    }

Grails doesn't support grouping properties with constraints, so the
sharing is on a per-property basis.

Peter

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[ccllc]

Wow Peter, no I hadn't heard anything about that - I'm a bit surprised it
didn't come up before when I was trying to figure out shared/inherited
constraints early this year.

So when did these referenced constraints become available? (Grails
version, etc.)

And are the grails.gorm... code snippets you gave from Config.groovy or
something else?

Thanks!

>> OTOH from my experience validation exceptions only work as a final
>> signal
>> from a complex validation system when you're working with a website and
>> any semi-complex object model.  While Grails does more aggregating of
>> validation errors than most other Java web frameworks (yay!), Grails is
>> stunted by the lack of consistently inheriting or referencing
>> constraints
>> thereby requiring copy-and-pasted code for command objects or most any
>> other rules sharing.
>
> You do know that you can now specify default constraints that apply to
> all domain classes and named ones that you can explicitly reference
> from your constraints blocks?
>
>     grails.gorm.default.constraints = {
>         '*'(nullable:true, blank:false, size:1..20)
>     }
>
> and
>
>     grails.gorm.default.constraints = {
>         myConstraints(nullable:true, blank:false, size:1..20)
>     }
>
>     static constraints = {
>         myProperty shared:"myConstraints"
>     }
>
> Grails doesn't support grouping properties with constraints, so the
> sharing is on a per-property basis.
>
> Peter

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[pledbrook]

> Wow Peter, no I hadn't heard anything about that - I'm a bit surprised it
> didn't come up before when I was trying to figure out shared/inherited
> constraints early this year.

It always pays to read the release notes. And there's enough volume on
this list that not everything gets answered I'm afraid. Sorry.

> So when did these referenced constraints become available? (Grails
> version, etc.)

Grails 1.2

> And are the grails.gorm... code snippets you gave from Config.groovy or
> something else?

Yes, Config.groovy.

Peter

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email