Date values (and perhaps also values of other primitive types) are not initialized automatically. As a result, they may be null and can cause exceptions on use. For example, sorting on uninitialized dates fails.

Submitted by Sander Vermolen on 31 May 2010 at 16:52

On 1 June 2010 at 08:34 Rob Vermaas commented:

-1 Vote ;-)

I think date(time) colums should be nullable. Maybe you could add a default constraint on the entity property?

On 1 June 2010 at 08:40 Eelco Visser commented:

I agree with Rob about nullability of fields. The annoying part is that sorting breaks, and in a bad way (templates break); that should be solved.

On 1 June 2010 at 10:01 Sander Vermolen commented:

I see. I am fine with nullable values, but let’s at least make the default value the current date/time (not null). I believe that current time is the most common use case for dates and it will work around the sorting problems as long as the programmer does not explicitly set dates to null.

On 1 June 2010 at 10:15 Lennart Kats commented:

Yes, as Eelco suggests this currently causes very subtle bugs. For instance, in Spoofax/103 I posted two comments that are not visible because there is one comment without a date stamp (YellowGrass/103). Apparently WebDSL throws an exception, swallows it, and hides the entire template. But maybe nullable initialization, handling of null values, and exceptions are separate issues?

On 1 June 2010 at 10:39 Rob Vermaas commented:

I think Lennart is right that he says these are seperate issues.

However, concerning Sanders remark, I don’t really see any point in initialization to current date(time) by default. It really depends on your application which behaviour you’d like to see. Therefore I see more in defining something like a default constraint on entity property which would make the choice explicit.

On 1 June 2010 at 11:08 Sander Vermolen commented:

Indeed these are separate issues, I believe we can all agree that in an ideal solution the sorting and the template would not break.

Separate from this, I agree with Rob that it depends on the type of application what initialization is desirable. I was just referring to a default case. I believe that initialization to current date is a more common scenario, than initialization to null (also looking at date implementations in other languages). Additionally, to novice users it may not be clear that null is indeed a valid date (me apparently being novice as well). On the other hand it is obvious that ‘now’ is a valid date.

Rob, I am not sure what type of constraint you refer to. I can imagine specifying an initialization value in the entity declaration. That would be nice and explicit, yet does not solve the problem of what the default initialization should be. Another possible constraint is specifying that a date primitive is optional or mandatory, which would also be nice and explicit, but may be a bit too much work to implement. Did you mean a different type of constraint?

Log in to post comments