Yes, I do that all the time: integer in the database and boolean in the model.
On the plus side when you (inevitably it seems) discover that your boolean
actually needs 4 values, migrating to an enum is simple since you can leave the
database alone and just change the model.
Remember the good
To the best of my knowledge thus should work on 3.1B2.
On Apr 22, 2013, at 1:36 PM, Markus Reich wrote:
> ok, thx for reply, I'm using version 3.1 B2, I'll try the newest version
>
> Meex
>
>
> 2013/4/22 Andrus Adamchik
>
>> Actually this should just work. No hacks are needed. But it shoul
ok, thx for reply, I'm using version 3.1 B2, I'll try the newest version
Meex
2013/4/22 Andrus Adamchik
> Actually this should just work. No hacks are needed. But it should be
> mapped as NUMBER on the DbEntity side, and as java.lang.Boolean - on the
> ObjEntity side. If it doesn't, it is a bu
Actually this should just work. No hacks are needed. But it should be mapped as
NUMBER on the DbEntity side, and as java.lang.Boolean - on the ObjEntity side.
If it doesn't, it is a bug that we need to fix.
Andrus
On Apr 22, 2013, at 4:51 AM, Markus Reich wrote:
> Hi,
>
> I've a problem with
I've always handled it by mapping the raw type, and creating Boolean
or boolean methods. You just need to make sure they have unique
names (you can reset the database accessors to end in get*Raw/set*Raw
if need be). Here's a contrived example.
public boolean isRecurring()
{
boo
Hi Markus,
I've always found booleans to be a little odd to work with, especially when
you have allows null. You could always define your own TRUE/FALSE enum (or
ExtendedEnumeration) as 1 and 0 respectively and then do:
ExpressionFactory.matchExp(MiiPickingcontainer.DELETED_PROPERTY,
MyEnum.FALS
