[Proposal] Criteria API over myBatis

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposal] Criteria API over myBatis

Andrea Selva
Hi list,
I would propose the creation of a submodule for myBatis that mimics the criteria API of other ORM, like Hibernate.
The basic idea is provide a simple API to create a set of criterion that generate the WHERE clause in a sql mapped statement.
I develop a skeletal poc for a project of mine, it could be found at http://bit.ly/iAIvUh

Thanks for attention
 Andrea Selva
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Criteria API over myBatis

nino martinez wael
Why not just support the JPA criteria api? If going in that direction?

2011/5/1 Andrea Selva <[hidden email]>:

> Hi list,
> I would propose the creation of a submodule for myBatis that mimics the
> criteria API of other ORM, like Hibernate.
> The basic idea is provide a simple API to create a set of criterion that
> generate the WHERE clause in a sql mapped statement.
> I develop a skeletal poc for a project of mine, it could be found at
> http://bit.ly/iAIvUh
>
> Thanks for attention
>  Andrea Selva
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Criteria API over myBatis

Andrea Selva
Yes it could be, at this moment the API are very very simple, so the direction could be easily changed.
 Andrea

On Mon, May 2, 2011 at 4:15 PM, nino martinez wael <[hidden email]> wrote:
Why not just support the JPA criteria api? If going in that direction?

2011/5/1 Andrea Selva <[hidden email]>:
> Hi list,
> I would propose the creation of a submodule for myBatis that mimics the
> criteria API of other ORM, like Hibernate.
> The basic idea is provide a simple API to create a set of criterion that
> generate the WHERE clause in a sql mapped statement.
> I develop a skeletal poc for a project of mine, it could be found at
> http://bit.ly/iAIvUh
>
> Thanks for attention
>  Andrea Selva
>

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Criteria API over myBatis

Simone Tripodi-2
@Andrea: we're evaluating your proposal, soon we will announce when
you'll join :P

@Nino: IMHO JPA APIs are a very different target. ORM != SqlMapping
even if it could be considered a superset.
uhmmm... let's reason about it, maybe there's a space for yet another
submodule... :P

Have a nice day!

Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Mon, May 2, 2011 at 4:32 PM, Andrea Selva <[hidden email]> wrote:

> Yes it could be, at this moment the API are very very simple, so the
> direction could be easily changed.
>  Andrea
>
> On Mon, May 2, 2011 at 4:15 PM, nino martinez wael
> <[hidden email]> wrote:
>>
>> Why not just support the JPA criteria api? If going in that direction?
>>
>> 2011/5/1 Andrea Selva <[hidden email]>:
>> > Hi list,
>> > I would propose the creation of a submodule for myBatis that mimics the
>> > criteria API of other ORM, like Hibernate.
>> > The basic idea is provide a simple API to create a set of criterion that
>> > generate the WHERE clause in a sql mapped statement.
>> > I develop a skeletal poc for a project of mine, it could be found at
>> > http://bit.ly/iAIvUh
>> >
>> > Thanks for attention
>> >  Andrea Selva
>> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Criteria API over myBatis

nino martinez wael
Simo..  I agree mybatis != JPA ... However JPA 2.0 has a very nice
criteria api, and it's only that part im talking about looks something
like this:

CriteriaBuilder queryBuilder = em.getCriteriaBuilder();
CriteriaQuery<Customer> queryDefinition =
queryBuilder.createQuery(Customer.class);
Root<Customer> customer = queryDefinition.from(Customer.class);
queryDefinition.select(customer).where(queryBuilder.equal(customer.get("firstName"),
"John"));

However im not sure if it has a separate api specification.. I just
don't see the reason to reinvent the wheel..

2011/5/2 Simone Tripodi <[hidden email]>:

> @Andrea: we're evaluating your proposal, soon we will announce when
> you'll join :P
>
> @Nino: IMHO JPA APIs are a very different target. ORM != SqlMapping
> even if it could be considered a superset.
> uhmmm... let's reason about it, maybe there's a space for yet another
> submodule... :P
>
> Have a nice day!
>
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, May 2, 2011 at 4:32 PM, Andrea Selva <[hidden email]> wrote:
>> Yes it could be, at this moment the API are very very simple, so the
>> direction could be easily changed.
>>  Andrea
>>
>> On Mon, May 2, 2011 at 4:15 PM, nino martinez wael
>> <[hidden email]> wrote:
>>>
>>> Why not just support the JPA criteria api? If going in that direction?
>>>
>>> 2011/5/1 Andrea Selva <[hidden email]>:
>>> > Hi list,
>>> > I would propose the creation of a submodule for myBatis that mimics the
>>> > criteria API of other ORM, like Hibernate.
>>> > The basic idea is provide a simple API to create a set of criterion that
>>> > generate the WHERE clause in a sql mapped statement.
>>> > I develop a skeletal poc for a project of mine, it could be found at
>>> > http://bit.ly/iAIvUh
>>> >
>>> > Thanks for attention
>>> >  Andrea Selva
>>> >
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Criteria API over myBatis

nino martinez wael
I guess one of the big pros are that mybatis does not have metadata
info needed for such an api?

Anyway just throwing out thoughts in public :)

2011/5/2 nino martinez wael <[hidden email]>:

> Simo..  I agree mybatis != JPA ... However JPA 2.0 has a very nice
> criteria api, and it's only that part im talking about looks something
> like this:
>
> CriteriaBuilder queryBuilder = em.getCriteriaBuilder();
> CriteriaQuery<Customer> queryDefinition =
> queryBuilder.createQuery(Customer.class);
> Root<Customer> customer = queryDefinition.from(Customer.class);
> queryDefinition.select(customer).where(queryBuilder.equal(customer.get("firstName"),
> "John"));
>
> However im not sure if it has a separate api specification.. I just
> don't see the reason to reinvent the wheel..
>
> 2011/5/2 Simone Tripodi <[hidden email]>:
>> @Andrea: we're evaluating your proposal, soon we will announce when
>> you'll join :P
>>
>> @Nino: IMHO JPA APIs are a very different target. ORM != SqlMapping
>> even if it could be considered a superset.
>> uhmmm... let's reason about it, maybe there's a space for yet another
>> submodule... :P
>>
>> Have a nice day!
>>
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, May 2, 2011 at 4:32 PM, Andrea Selva <[hidden email]> wrote:
>>> Yes it could be, at this moment the API are very very simple, so the
>>> direction could be easily changed.
>>>  Andrea
>>>
>>> On Mon, May 2, 2011 at 4:15 PM, nino martinez wael
>>> <[hidden email]> wrote:
>>>>
>>>> Why not just support the JPA criteria api? If going in that direction?
>>>>
>>>> 2011/5/1 Andrea Selva <[hidden email]>:
>>>> > Hi list,
>>>> > I would propose the creation of a submodule for myBatis that mimics the
>>>> > criteria API of other ORM, like Hibernate.
>>>> > The basic idea is provide a simple API to create a set of criterion that
>>>> > generate the WHERE clause in a sql mapped statement.
>>>> > I develop a skeletal poc for a project of mine, it could be found at
>>>> > http://bit.ly/iAIvUh
>>>> >
>>>> > Thanks for attention
>>>> >  Andrea Selva
>>>> >
>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Criteria API over myBatis

nino martinez wael
monologue..

I meant that the con for mybatis are that it does'nt have metadata or
a aware of primary keys etc, since users manage that.. If going toward
a JPA criteria like api..

2011/5/2 nino martinez wael <[hidden email]>:

> I guess one of the big pros are that mybatis does not have metadata
> info needed for such an api?
>
> Anyway just throwing out thoughts in public :)
>
> 2011/5/2 nino martinez wael <[hidden email]>:
>> Simo..  I agree mybatis != JPA ... However JPA 2.0 has a very nice
>> criteria api, and it's only that part im talking about looks something
>> like this:
>>
>> CriteriaBuilder queryBuilder = em.getCriteriaBuilder();
>> CriteriaQuery<Customer> queryDefinition =
>> queryBuilder.createQuery(Customer.class);
>> Root<Customer> customer = queryDefinition.from(Customer.class);
>> queryDefinition.select(customer).where(queryBuilder.equal(customer.get("firstName"),
>> "John"));
>>
>> However im not sure if it has a separate api specification.. I just
>> don't see the reason to reinvent the wheel..
>>
>> 2011/5/2 Simone Tripodi <[hidden email]>:
>>> @Andrea: we're evaluating your proposal, soon we will announce when
>>> you'll join :P
>>>
>>> @Nino: IMHO JPA APIs are a very different target. ORM != SqlMapping
>>> even if it could be considered a superset.
>>> uhmmm... let's reason about it, maybe there's a space for yet another
>>> submodule... :P
>>>
>>> Have a nice day!
>>>
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Mon, May 2, 2011 at 4:32 PM, Andrea Selva <[hidden email]> wrote:
>>>> Yes it could be, at this moment the API are very very simple, so the
>>>> direction could be easily changed.
>>>>  Andrea
>>>>
>>>> On Mon, May 2, 2011 at 4:15 PM, nino martinez wael
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Why not just support the JPA criteria api? If going in that direction?
>>>>>
>>>>> 2011/5/1 Andrea Selva <[hidden email]>:
>>>>> > Hi list,
>>>>> > I would propose the creation of a submodule for myBatis that mimics the
>>>>> > criteria API of other ORM, like Hibernate.
>>>>> > The basic idea is provide a simple API to create a set of criterion that
>>>>> > generate the WHERE clause in a sql mapped statement.
>>>>> > I develop a skeletal poc for a project of mine, it could be found at
>>>>> > http://bit.ly/iAIvUh
>>>>> >
>>>>> > Thanks for attention
>>>>> >  Andrea Selva
>>>>> >
>>>>
>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Criteria API over myBatis

Andrea Selva
I NinoI agree with you to not reinvent the wheel. The only con that I see is that MyBatis hasn't got an entity mapping definition, but could care only on ResultMap (guessing from entity class) or given explicitly by the client code.
 Another thing I see different from JPA and MyBatis is that in myBatis we could use the criterion only for the WHERE filter instead of all the wuery (SELECT and FROM parts).
 So this shift from JPA query made the submodule to use only part of JPA, but that could be a choice, be inspired by the already existing API but not be compatible.
 Andrea Selva
 


On Mon, May 2, 2011 at 7:59 PM, nino martinez wael <[hidden email]> wrote:
monologue..

I meant that the con for mybatis are that it does'nt have metadata or
a aware of primary keys etc, since users manage that.. If going toward
a JPA criteria like api..

2011/5/2 nino martinez wael <[hidden email]>:
> I guess one of the big pros are that mybatis does not have metadata
> info needed for such an api?
>
> Anyway just throwing out thoughts in public :)
>
> 2011/5/2 nino martinez wael <[hidden email]>:
>> Simo..  I agree mybatis != JPA ... However JPA 2.0 has a very nice
>> criteria api, and it's only that part im talking about looks something
>> like this:
>>
>> CriteriaBuilder queryBuilder = em.getCriteriaBuilder();
>> CriteriaQuery<Customer> queryDefinition =
>> queryBuilder.createQuery(Customer.class);
>> Root<Customer> customer = queryDefinition.from(Customer.class);
>> queryDefinition.select(customer).where(queryBuilder.equal(customer.get("firstName"),
>> "John"));
>>
>> However im not sure if it has a separate api specification.. I just
>> don't see the reason to reinvent the wheel..
>>
>> 2011/5/2 Simone Tripodi <[hidden email]>:
>>> @Andrea: we're evaluating your proposal, soon we will announce when
>>> you'll join :P
>>>
>>> @Nino: IMHO JPA APIs are a very different target. ORM != SqlMapping
>>> even if it could be considered a superset.
>>> uhmmm... let's reason about it, maybe there's a space for yet another
>>> submodule... :P
>>>
>>> Have a nice day!
>>>
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Mon, May 2, 2011 at 4:32 PM, Andrea Selva <[hidden email]> wrote:
>>>> Yes it could be, at this moment the API are very very simple, so the
>>>> direction could be easily changed.
>>>>  Andrea
>>>>
>>>> On Mon, May 2, 2011 at 4:15 PM, nino martinez wael
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Why not just support the JPA criteria api? If going in that direction?
>>>>>
>>>>> 2011/5/1 Andrea Selva <[hidden email]>:
>>>>> > Hi list,
>>>>> > I would propose the creation of a submodule for myBatis that mimics the
>>>>> > criteria API of other ORM, like Hibernate.
>>>>> > The basic idea is provide a simple API to create a set of criterion that
>>>>> > generate the WHERE clause in a sql mapped statement.
>>>>> > I develop a skeletal poc for a project of mine, it could be found at
>>>>> > http://bit.ly/iAIvUh
>>>>> >
>>>>> > Thanks for attention
>>>>> >  Andrea Selva
>>>>> >
>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Criteria API over myBatis

Raj Nagappan
Hi all, I think that:

1. Any API should deliberately NOT be the same as JPA, because then
either MyBatis has to conform to (that part of) the JPA spec properly,
or has to make it abundantly clear where it deviates from JPA in
behaviour. I think both of these are likely to lead to confusion,
especially as many people will assume that MyBatis is another JPA
implementation just like Hibernate, when it's actually not.

2. After thinking about this for a few days, I actually think any move
to "build" the SQL is a bad idea. MyBatis is an SQL mapping framework,
not an SQL generation tool. I actually like the fact that it forces
you to (mostly) retain the SQL and makes you think about the impact of
the query on the database. There are existing SQL generation tools
around like Squiggle and SqlBuilder, so I'd suggest leveraging those
instead.

Just my 2 cents,
Raj.

On May 3, 6:16 am, Andrea Selva <[hidden email]> wrote:

> I NinoI agree with you to not reinvent the wheel. The only con that I see is
> that MyBatis hasn't got an entity mapping definition, but could care only on
> ResultMap (guessing from entity class) or given explicitly by the client
> code.
>  Another thing I see different from JPA and MyBatis is that in myBatis we
> could use the criterion only for the WHERE filter instead of all the wuery
> (SELECT and FROM parts).
>  So this shift from JPA query made the submodule to use only part of JPA,
> but that could be a choice, be inspired by the already existing API but not
> be compatible.
>  Andrea Selva
>
> On Mon, May 2, 2011 at 7:59 PM, nino martinez wael <
>
> [hidden email]> wrote:
> > monologue..
>
> > I meant that the con for mybatis are that it does'nt have metadata or
> > a aware of primary keys etc, since users manage that.. If going toward
> > a JPA criteria like api..
>
> > 2011/5/2 nino martinez wael <[hidden email]>:
> > > I guess one of the big pros are that mybatis does not have metadata
> > > info needed for such an api?
>
> > > Anyway just throwing out thoughts in public :)
>
> > > 2011/5/2 nino martinez wael <[hidden email]>:
> > >> Simo..  I agree mybatis != JPA ... However JPA 2.0 has a very nice
> > >> criteria api, and it's only that part im talking about looks something
> > >> like this:
>
> > >> CriteriaBuilder queryBuilder = em.getCriteriaBuilder();
> > >> CriteriaQuery<Customer> queryDefinition =
> > >> queryBuilder.createQuery(Customer.class);
> > >> Root<Customer> customer = queryDefinition.from(Customer.class);
>
> > queryDefinition.select(customer).where(queryBuilder.equal(customer.get("firstName"),
> > >> "John"));
>
> > >> However im not sure if it has a separate api specification.. I just
> > >> don't see the reason to reinvent the wheel..
>
> > >> 2011/5/2 Simone Tripodi <[hidden email]>:
> > >>> @Andrea: we're evaluating your proposal, soon we will announce when
> > >>> you'll join :P
>
> > >>> @Nino: IMHO JPA APIs are a very different target. ORM != SqlMapping
> > >>> even if it could be considered a superset.
> > >>> uhmmm... let's reason about it, maybe there's a space for yet another
> > >>> submodule... :P
>
> > >>> Have a nice day!
>
> > >>> Simo
>
> > >>>http://people.apache.org/~simonetripodi/
> > >>>http://www.99soft.org/
>
> > >>> On Mon, May 2, 2011 at 4:32 PM, Andrea Selva <[hidden email]>
> > wrote:
> > >>>> Yes it could be, at this moment the API are very very simple, so the
> > >>>> direction could be easily changed.
> > >>>>  Andrea
>
> > >>>> On Mon, May 2, 2011 at 4:15 PM, nino martinez wael
> > >>>> <[hidden email]> wrote:
>
> > >>>>> Why not just support the JPA criteria api? If going in that
> > direction?
>
> > >>>>> 2011/5/1 Andrea Selva <[hidden email]>:
> > >>>>> > Hi list,
> > >>>>> > I would propose the creation of a submodule for myBatis that mimics
> > the
> > >>>>> > criteria API of other ORM, like Hibernate.
> > >>>>> > The basic idea is provide a simple API to create a set of criterion
> > that
> > >>>>> > generate the WHERE clause in a sql mapped statement.
> > >>>>> > I develop a skeletal poc for a project of mine, it could be found
> > at
> > >>>>> >http://bit.ly/iAIvUh
>
> > >>>>> > Thanks for attention
> > >>>>> >  Andrea Selva
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Criteria API over myBatis

Guy Rouillier
In reply to this post by nino martinez wael
On 5/2/2011 1:55 PM, nino martinez wael wrote:

> Simo..  I agree mybatis != JPA ... However JPA 2.0 has a very nice
> criteria api, and it's only that part im talking about looks something
> like this:
>
> CriteriaBuilder queryBuilder = em.getCriteriaBuilder();
> CriteriaQuery<Customer>  queryDefinition =
> queryBuilder.createQuery(Customer.class);
> Root<Customer>  customer = queryDefinition.from(Customer.class);
> queryDefinition.select(customer).where(queryBuilder.equal(customer.get("firstName"),
> "John"));
>
> However im not sure if it has a separate api specification.. I just
> don't see the reason to reinvent the wheel..

Have you taken a look at the Criteria class already generated by the
generator?  Perhaps it does what you want.

I really don't see a need for layering a criteria framework on top of
MyBatis.  You can already conditionally include any part of a SQL
statement in the XML using the <if> capability - select clause, where
clause, etc.  That seems sufficient to do everything you are doing above.

--
Guy Rouillier
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Criteria API over myBatis

nino martinez wael
yes.. I see the point..

But what I do think could be some default DAOS ala HADES for spring
and JPA.. Im not sure how much we would be able todo for reducing
boiler plate, but if you have a really simple database structure, we
should be able to reduce something..

ALA

@TABLE("mytable", MappedClass)
public interface reducedDAO extends boilplatedDAO

and then provide boiler plate methods like save update delete and
pagination, but it would only work if the table did not have
references for other tables when deleting or creating...?


HADES=http://hades.synyx.org/static/2.x/site/org.synyx.hades/reference/html/entities-and-daos.html

2011/5/3 Guy Rouillier <[hidden email]>:

> On 5/2/2011 1:55 PM, nino martinez wael wrote:
>>
>> Simo..  I agree mybatis != JPA ... However JPA 2.0 has a very nice
>> criteria api, and it's only that part im talking about looks something
>> like this:
>>
>> CriteriaBuilder queryBuilder = em.getCriteriaBuilder();
>> CriteriaQuery<Customer>  queryDefinition =
>> queryBuilder.createQuery(Customer.class);
>> Root<Customer>  customer = queryDefinition.from(Customer.class);
>>
>> queryDefinition.select(customer).where(queryBuilder.equal(customer.get("firstName"),
>> "John"));
>>
>> However im not sure if it has a separate api specification.. I just
>> don't see the reason to reinvent the wheel..
>
> Have you taken a look at the Criteria class already generated by the
> generator?  Perhaps it does what you want.
>
> I really don't see a need for layering a criteria framework on top of
> MyBatis.  You can already conditionally include any part of a SQL statement
> in the XML using the <if> capability - select clause, where clause, etc.
>  That seems sufficient to do everything you are doing above.
>
> --
> Guy Rouillier
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Criteria API over myBatis

Andrea Selva
@Raj: I agree with you on 1) to not say "MyBatis is JPA compatible" because this could never be true, but use exisisting API (Hibernate or Torque or JPA) as inspiration. I disagree on 2) because the Criteria API over myBatis is a complement to user defined SQL, an help for the WHERE part of the query, that do checks and generate the where condition being aware of the ResultMap.

I also like the power that MyBatis gives you, but having a choice could be a plus.

@Guy: I think that the generated Criteria from generator aren't so clean and simply to maintain, especially in xml mapper part. That complexity drove me to think about an alternative solution.

Best regards
 Andrea Selva

On Tue, May 3, 2011 at 7:41 AM, nino martinez wael <[hidden email]> wrote:
yes.. I see the point..

But what I do think could be some default DAOS ala HADES for spring
and JPA.. Im not sure how much we would be able todo for reducing
boiler plate, but if you have a really simple database structure, we
should be able to reduce something..

ALA

@TABLE("mytable", MappedClass)
public interface reducedDAO extends boilplatedDAO

and then provide boiler plate methods like save update delete and
pagination, but it would only work if the table did not have
references for other tables when deleting or creating...?


HADES=http://hades.synyx.org/static/2.x/site/org.synyx.hades/reference/html/entities-and-daos.html

2011/5/3 Guy Rouillier <[hidden email]>:
> On 5/2/2011 1:55 PM, nino martinez wael wrote:
>>
>> Simo..  I agree mybatis != JPA ... However JPA 2.0 has a very nice
>> criteria api, and it's only that part im talking about looks something
>> like this:
>>
>> CriteriaBuilder queryBuilder = em.getCriteriaBuilder();
>> CriteriaQuery<Customer>  queryDefinition =
>> queryBuilder.createQuery(Customer.class);
>> Root<Customer>  customer = queryDefinition.from(Customer.class);
>>
>> queryDefinition.select(customer).where(queryBuilder.equal(customer.get("firstName"),
>> "John"));
>>
>> However im not sure if it has a separate api specification.. I just
>> don't see the reason to reinvent the wheel..
>
> Have you taken a look at the Criteria class already generated by the
> generator?  Perhaps it does what you want.
>
> I really don't see a need for layering a criteria framework on top of
> MyBatis.  You can already conditionally include any part of a SQL statement
> in the XML using the <if> capability - select clause, where clause, etc.
>  That seems sufficient to do everything you are doing above.
>
> --
> Guy Rouillier
>

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Criteria API over myBatis

Clinton Begin
Administrator
We also have the SelectBuilder and SqlBuilder APIs...

Clinton

On Tue, May 3, 2011 at 2:05 AM, Andrea Selva <[hidden email]> wrote:
@Raj: I agree with you on 1) to not say "MyBatis is JPA compatible" because this could never be true, but use exisisting API (Hibernate or Torque or JPA) as inspiration. I disagree on 2) because the Criteria API over myBatis is a complement to user defined SQL, an help for the WHERE part of the query, that do checks and generate the where condition being aware of the ResultMap.

I also like the power that MyBatis gives you, but having a choice could be a plus.

@Guy: I think that the generated Criteria from generator aren't so clean and simply to maintain, especially in xml mapper part. That complexity drove me to think about an alternative solution.

Best regards
 Andrea Selva


On Tue, May 3, 2011 at 7:41 AM, nino martinez wael <[hidden email]> wrote:
yes.. I see the point..

But what I do think could be some default DAOS ala HADES for spring
and JPA.. Im not sure how much we would be able todo for reducing
boiler plate, but if you have a really simple database structure, we
should be able to reduce something..

ALA

@TABLE("mytable", MappedClass)
public interface reducedDAO extends boilplatedDAO

and then provide boiler plate methods like save update delete and
pagination, but it would only work if the table did not have
references for other tables when deleting or creating...?


HADES=http://hades.synyx.org/static/2.x/site/org.synyx.hades/reference/html/entities-and-daos.html

2011/5/3 Guy Rouillier <[hidden email]>:
> On 5/2/2011 1:55 PM, nino martinez wael wrote:
>>
>> Simo..  I agree mybatis != JPA ... However JPA 2.0 has a very nice
>> criteria api, and it's only that part im talking about looks something
>> like this:
>>
>> CriteriaBuilder queryBuilder = em.getCriteriaBuilder();
>> CriteriaQuery<Customer>  queryDefinition =
>> queryBuilder.createQuery(Customer.class);
>> Root<Customer>  customer = queryDefinition.from(Customer.class);
>>
>> queryDefinition.select(customer).where(queryBuilder.equal(customer.get("firstName"),
>> "John"));
>>
>> However im not sure if it has a separate api specification.. I just
>> don't see the reason to reinvent the wheel..
>
> Have you taken a look at the Criteria class already generated by the
> generator?  Perhaps it does what you want.
>
> I really don't see a need for layering a criteria framework on top of
> MyBatis.  You can already conditionally include any part of a SQL statement
> in the XML using the <if> capability - select clause, where clause, etc.
>  That seems sufficient to do everything you are doing above.
>
> --
> Guy Rouillier
>


Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Criteria API over myBatis

Simone Tripodi-2
Indeed, the Criteria APIs proposed by Andrea could be a nice
SelectBuilder and SqlBuilder addons...
It shouldn't necessary replace anything already existing, but be an extension.
WDYT?
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, May 3, 2011 at 8:02 PM, Clinton Begin <[hidden email]> wrote:

> We also have the SelectBuilder and SqlBuilder APIs...
> Clinton
>
> On Tue, May 3, 2011 at 2:05 AM, Andrea Selva <[hidden email]> wrote:
>>
>> @Raj: I agree with you on 1) to not say "MyBatis is JPA compatible"
>> because this could never be true, but use exisisting API (Hibernate or
>> Torque or JPA) as inspiration. I disagree on 2) because the Criteria API
>> over myBatis is a complement to user defined SQL, an help for the WHERE part
>> of the query, that do checks and generate the where condition being aware of
>> the ResultMap.
>>
>> I also like the power that MyBatis gives you, but having a choice could be
>> a plus.
>>
>> @Guy: I think that the generated Criteria from generator aren't so clean
>> and simply to maintain, especially in xml mapper part. That complexity drove
>> me to think about an alternative solution.
>>
>> Best regards
>>  Andrea Selva
>>
>> On Tue, May 3, 2011 at 7:41 AM, nino martinez wael
>> <[hidden email]> wrote:
>>>
>>> yes.. I see the point..
>>>
>>> But what I do think could be some default DAOS ala HADES for spring
>>> and JPA.. Im not sure how much we would be able todo for reducing
>>> boiler plate, but if you have a really simple database structure, we
>>> should be able to reduce something..
>>>
>>> ALA
>>>
>>> @TABLE("mytable", MappedClass)
>>> public interface reducedDAO extends boilplatedDAO
>>>
>>> and then provide boiler plate methods like save update delete and
>>> pagination, but it would only work if the table did not have
>>> references for other tables when deleting or creating...?
>>>
>>>
>>>
>>> HADES=http://hades.synyx.org/static/2.x/site/org.synyx.hades/reference/html/entities-and-daos.html
>>>
>>> 2011/5/3 Guy Rouillier <[hidden email]>:
>>> > On 5/2/2011 1:55 PM, nino martinez wael wrote:
>>> >>
>>> >> Simo..  I agree mybatis != JPA ... However JPA 2.0 has a very nice
>>> >> criteria api, and it's only that part im talking about looks something
>>> >> like this:
>>> >>
>>> >> CriteriaBuilder queryBuilder = em.getCriteriaBuilder();
>>> >> CriteriaQuery<Customer>  queryDefinition =
>>> >> queryBuilder.createQuery(Customer.class);
>>> >> Root<Customer>  customer = queryDefinition.from(Customer.class);
>>> >>
>>> >>
>>> >> queryDefinition.select(customer).where(queryBuilder.equal(customer.get("firstName"),
>>> >> "John"));
>>> >>
>>> >> However im not sure if it has a separate api specification.. I just
>>> >> don't see the reason to reinvent the wheel..
>>> >
>>> > Have you taken a look at the Criteria class already generated by the
>>> > generator?  Perhaps it does what you want.
>>> >
>>> > I really don't see a need for layering a criteria framework on top of
>>> > MyBatis.  You can already conditionally include any part of a SQL
>>> > statement
>>> > in the XML using the <if> capability - select clause, where clause,
>>> > etc.
>>> >  That seems sufficient to do everything you are doing above.
>>> >
>>> > --
>>> > Guy Rouillier
>>> >
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Criteria API over myBatis

Clinton Begin
Administrator
It's worth a shot... the community can evaluate and decide if it's worthwhile.  

I wish Java could create better DSLs... :-/

Cheers,
Clinton

On Tue, May 3, 2011 at 12:54 PM, Simone Tripodi <[hidden email]> wrote:
Indeed, the Criteria APIs proposed by Andrea could be a nice
SelectBuilder and SqlBuilder addons...
It shouldn't necessary replace anything already existing, but be an extension.
WDYT?
On Tue, May 3, 2011 at 8:02 PM, Clinton Begin <[hidden email]> wrote:
> We also have the SelectBuilder and SqlBuilder APIs...
> Clinton
>
> On Tue, May 3, 2011 at 2:05 AM, Andrea Selva <[hidden email]> wrote:
>>
>> @Raj: I agree with you on 1) to not say "MyBatis is JPA compatible"
>> because this could never be true, but use exisisting API (Hibernate or
>> Torque or JPA) as inspiration. I disagree on 2) because the Criteria API
>> over myBatis is a complement to user defined SQL, an help for the WHERE part
>> of the query, that do checks and generate the where condition being aware of
>> the ResultMap.
>>
>> I also like the power that MyBatis gives you, but having a choice could be
>> a plus.
>>
>> @Guy: I think that the generated Criteria from generator aren't so clean
>> and simply to maintain, especially in xml mapper part. That complexity drove
>> me to think about an alternative solution.
>>
>> Best regards
>>  Andrea Selva
>>
>> On Tue, May 3, 2011 at 7:41 AM, nino martinez wael
>> <[hidden email]> wrote:
>>>
>>> yes.. I see the point..
>>>
>>> But what I do think could be some default DAOS ala HADES for spring
>>> and JPA.. Im not sure how much we would be able todo for reducing
>>> boiler plate, but if you have a really simple database structure, we
>>> should be able to reduce something..
>>>
>>> ALA
>>>
>>> @TABLE("mytable", MappedClass)
>>> public interface reducedDAO extends boilplatedDAO
>>>
>>> and then provide boiler plate methods like save update delete and
>>> pagination, but it would only work if the table did not have
>>> references for other tables when deleting or creating...?
>>>
>>>
>>>
>>> HADES=http://hades.synyx.org/static/2.x/site/org.synyx.hades/reference/html/entities-and-daos.html
>>>
>>> 2011/5/3 Guy Rouillier <[hidden email]>:
>>> > On 5/2/2011 1:55 PM, nino martinez wael wrote:
>>> >>
>>> >> Simo..  I agree mybatis != JPA ... However JPA 2.0 has a very nice
>>> >> criteria api, and it's only that part im talking about looks something
>>> >> like this:
>>> >>
>>> >> CriteriaBuilder queryBuilder = em.getCriteriaBuilder();
>>> >> CriteriaQuery<Customer>  queryDefinition =
>>> >> queryBuilder.createQuery(Customer.class);
>>> >> Root<Customer>  customer = queryDefinition.from(Customer.class);
>>> >>
>>> >>
>>> >> queryDefinition.select(customer).where(queryBuilder.equal(customer.get("firstName"),
>>> >> "John"));
>>> >>
>>> >> However im not sure if it has a separate api specification.. I just
>>> >> don't see the reason to reinvent the wheel..
>>> >
>>> > Have you taken a look at the Criteria class already generated by the
>>> > generator?  Perhaps it does what you want.
>>> >
>>> > I really don't see a need for layering a criteria framework on top of
>>> > MyBatis.  You can already conditionally include any part of a SQL
>>> > statement
>>> > in the XML using the <if> capability - select clause, where clause,
>>> > etc.
>>> >  That seems sufficient to do everything you are doing above.
>>> >
>>> > --
>>> > Guy Rouillier
>>> >
>>
>
>