Re: Storage of Boolean in GenericEntity

[David E Jones]

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

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

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

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.

-David

You could maybe do something about #1 to convert true/false to Y/N, but you really can't do anything about #2... My opinion is this will make things more difficult, not easer. It will obfuscate and confuse, not open up and make clear.

smime.p7s
Description: S/MIME cryptographic signature