empire-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Döbele <doeb...@esteam.de>
Subject re: Constraint on the same column
Date Wed, 16 Sep 2015 07:37:28 GMT
Hi Ivan,

don’t worry about your English. I think it is pretty good.
Mine is not perfect either.

But yes, the design is, that a DBCommand can be reused and modified if desired.
In fact I have scenarios where this is pretty handy.


from: ivan.nemeth@gmail.com [mailto:ivan.nemeth@gmail.com] Im Auftrag von ivan nemeth
to: user
re: Re: Constraint on the same column

Hi Rainer,

thanks for your answer, now I see this could be an endless debate between us. ;-)
It's interesting what you say about command reusing. For me DBCommand is some kind of an "immutable",
short-lived object: create - configure - use once - drop away. I've never used the same DBCommand
more than once. This is a different approach than your's, and partly explains why we see this
issue so different.


(Sorry for my english, I know sometimes it is hard to understand what I want to say).

On Tue, Sep 15, 2015 at 4:54 PM, Rainer Döbele <doebele@esteam.de<mailto:doebele@esteam.de>>
Hi Ivan,

Thanks for giving us your option on this. However, I don’t quite share your point of view
(Provided that I understood your concern correctly).

In the same way that we’re not selecting the same column twice (unless you explicitly want
it) we also don’t – by default - add two or more constraints on the same column.
In 99.9% of all statements you won’t have two contraints on the same column – especially
not with an AND operator.
And in 99.9% of all scenarios where you reuse a command and put a constraint on a column that
already has a constraint on that column the user wants to replace the comparison value (e.g.
in loops).
Most constraints are equal-constraints anyway and two constraints on the same column with
different values would always result in an empty result.

Besides that I also don’t see the point that the other methods of DBCommand would behave
differently. Select, OrderBy, GroupBy and Having behave in the same way: they will not add
the same column twice.
So I think everything is pretty consistent except for the issue that you reported with the
addWhereConstraints method, when you add a list of constraints.
I agree, that to be 100% consistent we would have to treat every item of the list as if it
was added separately and hence allow only on constraint on each column.
This would really be an issue to talk about.


from: Ivan Nemeth [mailto:ivan.nemeth@gmail.com<mailto:ivan.nemeth@gmail.com>]
to: user
re: Re: Constraint on the same column

Hi Rainer,

I know it's not a bug and this is my problem. Empire has a very good balance between pure
SQL and Java and it's a very intuitive framework: you can think in SQL and code in Java at
the same time.
But this method is an exception. I would look DBCommand.where as an alternative to SQL's WHERE...AND
construct, but this is wrong. Unlike other Empire methods (select(), orderBy()) this method
doesn't do what I would expect: when you write a SQL you can put as many constraints on the
same column with an AND operator, and the last one doesn't hide the previous ones.
So in my opinion this method (in this form) slightly breaks Empire's logic.


On Fri, Sep 11, 2015 at 2:15 PM, Rainer Döbele <doebele@esteam.de<mailto:doebele@esteam.de>>
Hi Ivan,

generally if you want two constraints on the same column you must combine them with an AND
or OR operator.

The behavior to replace an existing constraint is by design.

IMO the behavior when providing a list of constraints is also OK, although one can argue that
the behavior should be the same.

But your other issue when providing an empty list is certainly a bug.
I will fix it immediately.


from: Ivan Nemeth [mailto:ivan.nemeth@gmail.com<mailto:ivan.nemeth@gmail.com>]
to: user
re: Constraint on the same column


another issue with constraints.

you can't add two constraint on the same column with DBCommand.where(DBCommandExpr expr) method.
The documentation says

"If another restriction already exists for the same column it will be replaced."

So if I want to query persons who's name starts with "A" but is not "Adam", I can do the following:


Due to the above mentioned restriction this won't work because the first constraint will be
dropped away, and I'll get ALL persons except Adam.

But if I use constraint list it's OK:

List wheres = new ArrayList();


View raw message