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? 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. 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.
