Is there an attribute to create a NOT NULL column on a persistent field (i.e. string type) ?

Hi Dan ;

No, it is not possible to create a not null column in a database table.
There are certainly reasons for this (some af them can be read in past
posts), but it would certainly be nice to be able to create a not nullable
column with a default value.

This might not work for every DB system, though.

Please have a look at this post (there are some earlier ones about it also
but the information is always the same) :

http://community.devexpress.com//forums/p/55123/185711.aspx#185711

Regards,

<Dan Arnold> wrote in message news:193327@community.devexpress.com...

Is there an attribute to create a NOT NULL column on a persistent field (i.e. string type) ?

---

http://community.devexpress.com//forums/p/57255/193327.aspx#193327

Almost every other ORM I have used including Genome, NHibernate, Xtensive DataObjects.Net ... allow definition of NOT NULL fields.

If a certain database does not support it, then just ignore the NOTNULL attribute.

This could easily be documented as an attriibute that is really just a hint, and that whether it has an efffect that depends on the backing store.

Why is it that other ORMS that support multiple backends are able to pull this off? And DevExpress is Not?

I'm hoping this issue gets re-evaulated in the future, maybe by hte XAF team, and changed.

 

Thanks,

Dan

Hi Dan,

Just out of curiosity, why would you need to set a DB-field as not nullable? What would be a good reason to do so?

One cannot dissociate the "Not Nullable" from a "Default Value". If the field is not nullable, it has to have a default value, or else it will be hard/impossible to keep backward compatibility of the application.

In the process of maintaining an application, new object properties (and thus DB-fields) get created, others get deprecated and disappear from the XPObject, thus not being referenced in the automatically generated SQLs.

XPO will not delete deprecated fields nor change the field type automatically, varchar to int, for example, althougth there is a discussion about this point.

There are some advantages to work with not nuallable fields, but I haven't tested whether it is noticable.
Not nullable fields do not require an extra hidden bit field telling if the value is null or not, creating slightly smaller DBs and faster indexes. The same is true for .NET nullable types, which are structures with a hidden boolean field.
Is this the reason why you need to have not nullable fields?

Regards,