Re: Storage of Boolean in GenericEntity

[David E Jones]

Adam,







So:

1. small issue; not going to save anyone any significant amount of time
2. bad for the best practices tools



http://docs.ofbiz.org/display/OFBADMIN/Best+Practices+Guide

-David


On Oct 15, 2007, at 3:50 PM, Adam Heath wrote:

It's pretty clear you like this idea and don't want to back down, so I'm not going to push back. What is wrong with the code already in the GenericEntity.java file that does this boolean conversion? As far as making it a best practice goes... maybe you should read through the best practices list and see if you can find where it might for it. For form, screen, tree, and menu widgets and for simple- methods it's a non-issue as Y/N are actually easier and less confusing (zero mapping beats single mapping any day). This only has an effect for business logic written Java, and I think that's a bad idea in the first place. If you want to argue with the best practices... feel free to start up a thread, just try to keep in mind limited resources, better things to work on for EVERYONE, and general ROI (starting with proving any sort of return, before even thinking about the investment required).

David E Jones wrote:

On Oct 15, 2007, at 1:52 PM, Adam Heath wrote:

David E Jones wrote:

with:

1. seed/setup data files
2. the database itself (for debugging, integrations, and so on)


If we just change #3 that would leave the other 2 inconsistent and

I'm missing in my quick thoughts on this.

The Entity Engine rather intentionally does not try to hide things like this. Generally people working on applications have access to and work 3. the code dealing with the field (writing, querying, comparing, etc) confusing. Also in addition to #1 and #2 there are probably other things

with strings for booleans?

Anything in java code should deal with java values. We don't deal with strings when dealing with ints, floats, BigDecimal. Why should we deal

types in SQL.

Because they aren't booleans. There is no good standard for boolean data

The entity engine allows java code to deal with booleans, and *does*

be treated as booleans in the application code.

give a cross-database encoding for booleans. Just because these fields are not stored as booleans in the database, doesn't mean they shouldn't

The entityengine is supposed to hide all database-specific code from the application; but storing the Y/N for boolean in the java maps does *not*

accomplish that goal.

That is NOT the goal of the Entity Engine. It does NOT hide the

database, it makes it easier to work with the database, and that's all.

And dealing with booleans in application code *is* easier than dealing
with "Y"/"N".

Are you saying strings are easier than booleans?  Is that what you are
*really* saying?

Hiding the database is a BAD idea and makes various things harder, like

understanding application data structures, optimizing queries and
understanding why queries are slow, keeping structures free of
redundancy, and so on.

There is redundant code all over dealing with "Y"/"N", instead of
boolean values.  Think about scripting code that can automatically
handle boxed booleans natively; using "Y"/"N" does not allow such
unboxing to take place.

I never suggested just changing how GenericEntity deals with booleans. Obviously all other parts of the code would need to be updated to deal

with booleans natively.

you really can't do anything about #2...

You could maybe do something about #1 to convert true/false to Y/ N, but

 HTTP parameters can be encoded as Y/N as well.  And seed xml files.
But the in-memory specification should be native java objects.

All other field types are native objects;
clob/blob/timestamp/date/time/float/double/integer/long/BigDecimal.
Only boolean is special.  Remove the special casing.

The database will store it as Y/N, handling during read/write from jdbc.

My opinion is this will make things more difficult, not easer. It will

obfuscate and confuse, not open up and make clear.

Well, I think your wrong there.  Seeing a "Y"/"N" in the code makes me

or something else.  A boolean type is obvious.

questioning if the field is a single character, holding "Y"/"N"/"A"/"1",

smime.p7s
Description: S/MIME cryptographic signature