David E Jones wrote: > > On Oct 15, 2007, at 1:52 PM, Adam Heath wrote: > >> David E Jones wrote: >>> >>> The Entity Engine rather intentionally does not try to hide things like >>> this. Generally people working on applications have access to and work >>> with: >>> >>> 1. seed/setup data files >>> 2. the database itself (for debugging, integrations, and so on) >>> 3. the code dealing with the field (writing, querying, comparing, etc) >>> >>> If we just change #3 that would leave the other 2 inconsistent and >>> confusing. Also in addition to #1 and #2 there are probably other things >>> I'm missing in my quick thoughts on this. >> >> 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 >> with strings for booleans? > > Because they aren't booleans. There is no good standard for boolean data > types in SQL.
The entity engine allows java code to deal with booleans, and *does* 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 be treated as booleans in the application code. >> 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 could maybe do something about #1 to convert true/false to Y/N, but > you really can't do anything about #2... The database will store it as Y/N, handling during read/write from jdbc. 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. > 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 questioning if the field is a single character, holding "Y"/"N"/"A"/"1", or something else. A boolean type is obvious.
