incubator-empire-db-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Döbele <>
Subject re: Empty Strings are not Null!
Date Tue, 27 Oct 2009 09:08:35 GMT
Hi Andrew,

there are many problem with empty strings in databases like e.g. that they allow to store
empty content in a "not null" field. The question is what is in fact the difference between
an empty field and a null value from a logical point of view. Personally I would even go as
far as to say "to distinguish empty strings from null does not make sense at all".

In order to avoid many problems inherit in empty strings Empire-db's aim is to treat empty
strings equivalent to null. More specifically Empire-db will always replace empty strings
by null and thus not allow empty strings to be written to the db. This behavior is by design
and brings many benefits especially regarding DBMS independence.

In DbRowSet like 680 that you mentioned we do exactly that i.e. we won't accept an empty string
for a required field. Allowing that would mean a back-door to bypass the "not null" constraint
on the column.

So again this works exactly as designed and I perceive this as a benefit and not as a restriction.



andrew cooke wrote:
> re: Empty Strings are not Null!
> I almost raised an issue for this, but then I started thinking it was
> odd that no-one else had ever mentioned it, so I thought maybe it was
> better to ask via email first...
> As far as I can tell, Empire DB will refuse to write an empty string
> to a column if it is "NOT NULL".  This is true for any database type
> since the logic based on a call to ObjectUtils - it's not the
> responsibility of a particular engine's driver (in my particular case
> the error is coming from DbRowSet line 680 as I add a new row).
> Now I know that Oracle, and perhaps some other databases, store empty
> strings as nulls. But not all databases do so!  I am pretty sure that
> HSQLDB does not, for example, since 1.7.2 - see
>  And I am also pretty
> sure that SQL standards make a distinction.
> So could this be fixed?  Alternatively, if it's a known issue that has
> a reason, is it documented somewhere?  Or if I've messed up, and this
> *does* work, please say so I can fix my bug...
> (I'm not really sure why Empire DB is checking this at all.  Isn't
> this the database's job?)
> Thanks,
> Andrew

View raw message