You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@continuum.apache.org by Rahul Thakur <ra...@gmail.com> on 2008/02/22 02:54:48 UTC
ContinuumStore refactoring
Hi,
I'd like to go ahead and pick up something towards the next Continuum
iteration. I am thinking refactoring ContinuumStore interface as was
earlier discussed on this list and as I did on the 'continuum-jpa'
branch.
To this end, I need to get a clear picture on a few items:
1) Which JPA provider are we going ahead with then?
2) Criteria vs Named Queries: I am not convinced (yet) that Named
queries are the way to go. I did some digging around, they are indeed
best practices for JPA but I think the decision merits other
consideration(s). I still believe the Criteria Queries will help us
define a cleaner Store interface.
3) Using Criteria Queries would mean that we use JPA extensions
specific to provider. I don't see this as an issue as long as we are
not expecting underlying JPA providers to be swapped. Thoughts?
Look forward to hear.
Cheers,
Rahul
Re: ContinuumStore refactoring
Posted by Rahul Thakur <ra...@gmail.com>.
Thanks Emmanuel,
I will take a look this weekend (still trying to get system back to life
after recent crash) .
Cheers,
Rahul
Emmanuel Venisse wrote:
> ok, the base is done. You can look at it.
>
> Team, can you look at my JPA branch and at the Rahul's one too and let us
> know what you think about them and which method you'd want to use in
> Continuum.
>
> Thanks
> Emmanuel
>
> On Wed, Apr 30, 2008 at 6:19 AM, Emmanuel Venisse<
> emmanuel.venisse@gmail.com> wrote:
>
>> The sample is ready, I'll try to clean the code in the train and commit it
>> tonight.
>> I wanted to use Spring annotations for auto-configuration instead of the
>> sping conf file, but it isn't important and out of topic for the sample.
>>
>> Emmanuel
>>
>>
>> On Tue, Apr 29, 2008 at 5:57 AM, Rahul Thakur<ra...@gmail.com>
>> wrote:
>>
>>> Hi Emmanuel,
>>>
>>> Just wondering if you hacked some samples? :-)
>>>
>>> Cheers,
>>> Rahul
>>>
>>>
>>>
>>>
>>> Emmanuel Venisse wrote:
>>>
>>>> I'll create some examples asap.
>>>>
>>>> Emmanuel
>>>>
>>>> On Thu, Feb 28, 2008 at 4:07 AM, Rahul Thakur<
>>>> rahul.thakur.xdev@gmail.com>
>>>> wrote:
>>>>
>>>> Hi,
>>>>> Some code using a couple of Entities as examples would be nice :-)
>>>>>
>>>>> I still think the API would be verbose.
>>>>>
>>>>> Thanks,
>>>>> Rahul
>>>>>
>>>>>
>>>>> On Fri, Feb 22, 2008 at 11:06 PM, Emmanuel Venisse
>>>>> <em...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur<
>>>>>>
>>>>> rahul.thakur.xdev@gmail.com>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> 2) Criteria vs Named Queries: I am not convinced (yet) that
>>>>>>>>> Named
>>>>>>>>> queries are the way to go. I did some digging around, they
>>>>>>>>> are
>>>>>>>>>
>>>>>>>> indeed
>>>>>> best practices for JPA but I think the decision merits other
>>>>>>>>> consideration(s). I still believe the Criteria Queries will
>>>>>>>>> help us
>>>>>>>>> define a cleaner Store interface.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I'm always in favor of named queries.
>>>>>>>> An other point about them that I haven't explain in previous
>>>>>>>> threads
>>>>>>>>
>>>>>>> (I
>>>>>> think) is that with named queries, it is possible to modify
>>>>>>>> queries
>>>>>>>> externally with xml files so if with a DB we have some
>>>>>>>> performance
>>>>>>>>
>>>>>>> issues,
>>>>>>> it will be possible to override queries by a modified JPQL query
>>>>>>>> or
>>>>>>>>
>>>>>>> a
>>>>>> native
>>>>>>
>>>>>>> query.
>>>>>>>> How do you see the refactored ContinuumStore interface using
>>>>>>> Named
>>>>>>> Queries? I suspect it will be just as verbose again.
>>>>>>>
>>>>>> I don't want to see a new time a big class for the store part. it
>>>>>> must
>>>>>>
>>>>> be
>>>>>
>>>>>> splitted in few domains.
>>>>>> All named queries related to Project would be defined in the
>>>>>> Project
>>>>>>
>>>>> class,
>>>>>
>>>>>> all named queries related to ProjectGroup would be defined in the
>>>>>> ProjectGroup class...
>>>>>>
>>>>>> And we can add some more classes for particular results that
>>>>>> aren't
>>>>>>
>>>>> entities
>>>>>
>>>>>> objects (we won't have a lot)
>>>>>>
>>>>>> With this, all concerns are separated and linked to a specific
>>>>>> entity.
>>>>>>
>>>>> Easy
>>>>>
>>>>>> to code, easy to read, easy to understand. It's my opinion.
>>>>>>
>>>>>> Sorry, still not convinced ;-)
>>>>>> I hope you are now ;-)
>>>>>>
>>>>>> Emmanuel
>>>>>>
>>>>>>> Rahul
>>>>>>>
>>>>>>>
>
Re: ContinuumStore refactoring
Posted by Emmanuel Venisse <em...@gmail.com>.
ok, the base is done. You can look at it.
Team, can you look at my JPA branch and at the Rahul's one too and let us
know what you think about them and which method you'd want to use in
Continuum.
Thanks
Emmanuel
On Wed, Apr 30, 2008 at 6:19 AM, Emmanuel Venisse <
emmanuel.venisse@gmail.com> wrote:
> The sample is ready, I'll try to clean the code in the train and commit it
> tonight.
> I wanted to use Spring annotations for auto-configuration instead of the
> sping conf file, but it isn't important and out of topic for the sample.
>
> Emmanuel
>
>
> On Tue, Apr 29, 2008 at 5:57 AM, Rahul Thakur <ra...@gmail.com>
> wrote:
>
> > Hi Emmanuel,
> >
> > Just wondering if you hacked some samples? :-)
> >
> > Cheers,
> > Rahul
> >
> >
> >
> >
> > Emmanuel Venisse wrote:
> >
> > > I'll create some examples asap.
> > >
> > > Emmanuel
> > >
> > > On Thu, Feb 28, 2008 at 4:07 AM, Rahul Thakur<
> > > rahul.thakur.xdev@gmail.com>
> > > wrote:
> > >
> > > Hi,
> > > >
> > > > Some code using a couple of Entities as examples would be nice :-)
> > > >
> > > > I still think the API would be verbose.
> > > >
> > > > Thanks,
> > > > Rahul
> > > >
> > > >
> > > > On Fri, Feb 22, 2008 at 11:06 PM, Emmanuel Venisse
> > > > <em...@gmail.com> wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur<
> > > > >
> > > > rahul.thakur.xdev@gmail.com>
> > > >
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > 2) Criteria vs Named Queries: I am not convinced (yet) that
> > > > > > > > Named
> > > > > > > > queries are the way to go. I did some digging around, they
> > > > > > > > are
> > > > > > > >
> > > > > > > indeed
> > > >
> > > > > best practices for JPA but I think the decision merits other
> > > > > > > > consideration(s). I still believe the Criteria Queries will
> > > > > > > > help us
> > > > > > > > define a cleaner Store interface.
> > > > > > > >
> > > > > > > >
> > > > > > > I'm always in favor of named queries.
> > > > > > > An other point about them that I haven't explain in previous
> > > > > > > threads
> > > > > > >
> > > > > > (I
> > > >
> > > > > think) is that with named queries, it is possible to modify
> > > > > > > queries
> > > > > > > externally with xml files so if with a DB we have some
> > > > > > > performance
> > > > > > >
> > > > > > issues,
> > > > >
> > > > > > it will be possible to override queries by a modified JPQL query
> > > > > > > or
> > > > > > >
> > > > > > a
> > > >
> > > > > native
> > > > >
> > > > > > query.
> > > > > > >
> > > > > > > How do you see the refactored ContinuumStore interface using
> > > > > > Named
> > > > > > Queries? I suspect it will be just as verbose again.
> > > > > >
> > > > > I don't want to see a new time a big class for the store part. it
> > > > > must
> > > > >
> > > > be
> > > >
> > > > > splitted in few domains.
> > > > > All named queries related to Project would be defined in the
> > > > > Project
> > > > >
> > > > class,
> > > >
> > > > > all named queries related to ProjectGroup would be defined in the
> > > > > ProjectGroup class...
> > > > >
> > > > > And we can add some more classes for particular results that
> > > > > aren't
> > > > >
> > > > entities
> > > >
> > > > > objects (we won't have a lot)
> > > > >
> > > > > With this, all concerns are separated and linked to a specific
> > > > > entity.
> > > > >
> > > > Easy
> > > >
> > > > > to code, easy to read, easy to understand. It's my opinion.
> > > > >
> > > > > Sorry, still not convinced ;-)
> > > > > >
> > > > > I hope you are now ;-)
> > > > >
> > > > > Emmanuel
> > > > >
> > > > > >
> > > > > > Rahul
> > > > > >
> > > > > >
> > > > >
> > >
>
Re: ContinuumStore refactoring
Posted by Emmanuel Venisse <em...@gmail.com>.
The sample is ready, I'll try to clean the code in the train and commit it
tonight.
I wanted to use Spring annotations for auto-configuration instead of the
sping conf file, but it isn't important and out of topic for the sample.
Emmanuel
On Tue, Apr 29, 2008 at 5:57 AM, Rahul Thakur <ra...@gmail.com>
wrote:
> Hi Emmanuel,
>
> Just wondering if you hacked some samples? :-)
>
> Cheers,
> Rahul
>
>
>
>
> Emmanuel Venisse wrote:
>
> > I'll create some examples asap.
> >
> > Emmanuel
> >
> > On Thu, Feb 28, 2008 at 4:07 AM, Rahul Thakur<
> > rahul.thakur.xdev@gmail.com>
> > wrote:
> >
> > Hi,
> > >
> > > Some code using a couple of Entities as examples would be nice :-)
> > >
> > > I still think the API would be verbose.
> > >
> > > Thanks,
> > > Rahul
> > >
> > >
> > > On Fri, Feb 22, 2008 at 11:06 PM, Emmanuel Venisse
> > > <em...@gmail.com> wrote:
> > >
> > > >
> > > >
> > > >
> > > > On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur<
> > > >
> > > rahul.thakur.xdev@gmail.com>
> > >
> > > > wrote:
> > > >
> > > > >
> > > > > 2) Criteria vs Named Queries: I am not convinced (yet) that
> > > > > > > Named
> > > > > > > queries are the way to go. I did some digging around, they are
> > > > > > >
> > > > > > indeed
> > >
> > > > best practices for JPA but I think the decision merits other
> > > > > > > consideration(s). I still believe the Criteria Queries will
> > > > > > > help us
> > > > > > > define a cleaner Store interface.
> > > > > > >
> > > > > > >
> > > > > > I'm always in favor of named queries.
> > > > > > An other point about them that I haven't explain in previous
> > > > > > threads
> > > > > >
> > > > > (I
> > >
> > > > think) is that with named queries, it is possible to modify queries
> > > > > > externally with xml files so if with a DB we have some
> > > > > > performance
> > > > > >
> > > > > issues,
> > > >
> > > > > it will be possible to override queries by a modified JPQL query
> > > > > > or
> > > > > >
> > > > > a
> > >
> > > > native
> > > >
> > > > > query.
> > > > > >
> > > > > > How do you see the refactored ContinuumStore interface using
> > > > > Named
> > > > > Queries? I suspect it will be just as verbose again.
> > > > >
> > > > I don't want to see a new time a big class for the store part. it
> > > > must
> > > >
> > > be
> > >
> > > > splitted in few domains.
> > > > All named queries related to Project would be defined in the Project
> > > >
> > > class,
> > >
> > > > all named queries related to ProjectGroup would be defined in the
> > > > ProjectGroup class...
> > > >
> > > > And we can add some more classes for particular results that aren't
> > > >
> > > entities
> > >
> > > > objects (we won't have a lot)
> > > >
> > > > With this, all concerns are separated and linked to a specific
> > > > entity.
> > > >
> > > Easy
> > >
> > > > to code, easy to read, easy to understand. It's my opinion.
> > > >
> > > > Sorry, still not convinced ;-)
> > > > >
> > > > I hope you are now ;-)
> > > >
> > > > Emmanuel
> > > >
> > > > >
> > > > > Rahul
> > > > >
> > > > >
> > > >
> >
Re: ContinuumStore refactoring
Posted by Rahul Thakur <ra...@gmail.com>.
Hi Emmanuel,
Just wondering if you hacked some samples? :-)
Cheers,
Rahul
Emmanuel Venisse wrote:
> I'll create some examples asap.
>
> Emmanuel
>
> On Thu, Feb 28, 2008 at 4:07 AM, Rahul Thakur<ra...@gmail.com>
> wrote:
>
>> Hi,
>>
>> Some code using a couple of Entities as examples would be nice :-)
>>
>> I still think the API would be verbose.
>>
>> Thanks,
>> Rahul
>>
>>
>> On Fri, Feb 22, 2008 at 11:06 PM, Emmanuel Venisse
>> <em...@gmail.com> wrote:
>>>
>>>
>>>
>>> On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur<
>> rahul.thakur.xdev@gmail.com>
>>> wrote:
>>>>
>>>>>> 2) Criteria vs Named Queries: I am not convinced (yet) that Named
>>>>>> queries are the way to go. I did some digging around, they are
>> indeed
>>>>>> best practices for JPA but I think the decision merits other
>>>>>> consideration(s). I still believe the Criteria Queries will help us
>>>>>> define a cleaner Store interface.
>>>>>>
>>>>>
>>>>> I'm always in favor of named queries.
>>>>> An other point about them that I haven't explain in previous threads
>> (I
>>>>> think) is that with named queries, it is possible to modify queries
>>>>> externally with xml files so if with a DB we have some performance
>>> issues,
>>>>> it will be possible to override queries by a modified JPQL query or
>> a
>>> native
>>>>> query.
>>>>>
>>>> How do you see the refactored ContinuumStore interface using Named
>>>> Queries? I suspect it will be just as verbose again.
>>> I don't want to see a new time a big class for the store part. it must
>> be
>>> splitted in few domains.
>>> All named queries related to Project would be defined in the Project
>> class,
>>> all named queries related to ProjectGroup would be defined in the
>>> ProjectGroup class...
>>>
>>> And we can add some more classes for particular results that aren't
>> entities
>>> objects (we won't have a lot)
>>>
>>> With this, all concerns are separated and linked to a specific entity.
>> Easy
>>> to code, easy to read, easy to understand. It's my opinion.
>>>
>>>> Sorry, still not convinced ;-)
>>> I hope you are now ;-)
>>>
>>> Emmanuel
>>>>
>>>> Rahul
>>>>
>>>
>
Re: ContinuumStore refactoring
Posted by Emmanuel Venisse <em...@gmail.com>.
I'll create some examples asap.
Emmanuel
On Thu, Feb 28, 2008 at 4:07 AM, Rahul Thakur <ra...@gmail.com>
wrote:
> Hi,
>
> Some code using a couple of Entities as examples would be nice :-)
>
> I still think the API would be verbose.
>
> Thanks,
> Rahul
>
>
> On Fri, Feb 22, 2008 at 11:06 PM, Emmanuel Venisse
> <em...@gmail.com> wrote:
> >
> >
> >
> >
> > On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur <
> rahul.thakur.xdev@gmail.com>
> > wrote:
> > >
> > >
> > > >> 2) Criteria vs Named Queries: I am not convinced (yet) that Named
> > > >> queries are the way to go. I did some digging around, they are
> indeed
> > > >> best practices for JPA but I think the decision merits other
> > > >> consideration(s). I still believe the Criteria Queries will help us
> > > >> define a cleaner Store interface.
> > > >>
> > > >
> > > >
> > > > I'm always in favor of named queries.
> > > > An other point about them that I haven't explain in previous threads
> (I
> > > > think) is that with named queries, it is possible to modify queries
> > > > externally with xml files so if with a DB we have some performance
> > issues,
> > > > it will be possible to override queries by a modified JPQL query or
> a
> > native
> > > > query.
> > > >
> > >
> > > How do you see the refactored ContinuumStore interface using Named
> > > Queries? I suspect it will be just as verbose again.
> >
> > I don't want to see a new time a big class for the store part. it must
> be
> > splitted in few domains.
> > All named queries related to Project would be defined in the Project
> class,
> > all named queries related to ProjectGroup would be defined in the
> > ProjectGroup class...
> >
> > And we can add some more classes for particular results that aren't
> entities
> > objects (we won't have a lot)
> >
> > With this, all concerns are separated and linked to a specific entity.
> Easy
> > to code, easy to read, easy to understand. It's my opinion.
> >
> > >
> > > Sorry, still not convinced ;-)
> >
> > I hope you are now ;-)
> >
> > Emmanuel
> > >
> > >
> > > Rahul
> > >
> >
> >
>
Re: ContinuumStore refactoring
Posted by Rahul Thakur <ra...@gmail.com>.
Hi,
Some code using a couple of Entities as examples would be nice :-)
I still think the API would be verbose.
Thanks,
Rahul
On Fri, Feb 22, 2008 at 11:06 PM, Emmanuel Venisse
<em...@gmail.com> wrote:
>
>
>
>
> On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur <ra...@gmail.com>
> wrote:
> >
> >
> > >> 2) Criteria vs Named Queries: I am not convinced (yet) that Named
> > >> queries are the way to go. I did some digging around, they are indeed
> > >> best practices for JPA but I think the decision merits other
> > >> consideration(s). I still believe the Criteria Queries will help us
> > >> define a cleaner Store interface.
> > >>
> > >
> > >
> > > I'm always in favor of named queries.
> > > An other point about them that I haven't explain in previous threads (I
> > > think) is that with named queries, it is possible to modify queries
> > > externally with xml files so if with a DB we have some performance
> issues,
> > > it will be possible to override queries by a modified JPQL query or a
> native
> > > query.
> > >
> >
> > How do you see the refactored ContinuumStore interface using Named
> > Queries? I suspect it will be just as verbose again.
>
> I don't want to see a new time a big class for the store part. it must be
> splitted in few domains.
> All named queries related to Project would be defined in the Project class,
> all named queries related to ProjectGroup would be defined in the
> ProjectGroup class...
>
> And we can add some more classes for particular results that aren't entities
> objects (we won't have a lot)
>
> With this, all concerns are separated and linked to a specific entity. Easy
> to code, easy to read, easy to understand. It's my opinion.
>
> >
> > Sorry, still not convinced ;-)
>
> I hope you are now ;-)
>
> Emmanuel
> >
> >
> > Rahul
> >
>
>
Re: ContinuumStore refactoring
Posted by Emmanuel Venisse <em...@gmail.com>.
On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur <ra...@gmail.com>
wrote:
>
> >> 2) Criteria vs Named Queries: I am not convinced (yet) that Named
> >> queries are the way to go. I did some digging around, they are indeed
> >> best practices for JPA but I think the decision merits other
> >> consideration(s). I still believe the Criteria Queries will help us
> >> define a cleaner Store interface.
> >>
> >
> >
> > I'm always in favor of named queries.
> > An other point about them that I haven't explain in previous threads (I
> > think) is that with named queries, it is possible to modify queries
> > externally with xml files so if with a DB we have some performance
> issues,
> > it will be possible to override queries by a modified JPQL query or a
> native
> > query.
> >
>
> How do you see the refactored ContinuumStore interface using Named
> Queries? I suspect it will be just as verbose again.
I don't want to see a new time a big class for the store part. it must be
splitted in few domains.
All named queries related to Project would be defined in the Project class,
all named queries related to ProjectGroup would be defined in the
ProjectGroup class...
And we can add some more classes for particular results that aren't entities
objects (we won't have a lot)
With this, all concerns are separated and linked to a specific entity. Easy
to code, easy to read, easy to understand. It's my opinion.
>
> Sorry, still not convinced ;-)
I hope you are now ;-)
Emmanuel
>
>
> Rahul
>
Re: ContinuumStore refactoring
Posted by Rahul Thakur <ra...@gmail.com>.
>> 2) Criteria vs Named Queries: I am not convinced (yet) that Named
>> queries are the way to go. I did some digging around, they are indeed
>> best practices for JPA but I think the decision merits other
>> consideration(s). I still believe the Criteria Queries will help us
>> define a cleaner Store interface.
>>
>
>
> I'm always in favor of named queries.
> An other point about them that I haven't explain in previous threads (I
> think) is that with named queries, it is possible to modify queries
> externally with xml files so if with a DB we have some performance issues,
> it will be possible to override queries by a modified JPQL query or a native
> query.
>
How do you see the refactored ContinuumStore interface using Named
Queries? I suspect it will be just as verbose again.
Sorry, still not convinced ;-)
Rahul
Re: ContinuumStore refactoring
Posted by Emmanuel Venisse <em...@gmail.com>.
As I already explained, I'm in favor of named queries
On Fri, Feb 22, 2008 at 2:54 AM, Rahul Thakur <ra...@gmail.com>
wrote:
> Hi,
>
> I'd like to go ahead and pick up something towards the next Continuum
> iteration. I am thinking refactoring ContinuumStore interface as was
> earlier discussed on this list and as I did on the 'continuum-jpa'
> branch.
>
> To this end, I need to get a clear picture on a few items:
>
> 1) Which JPA provider are we going ahead with then?
I'd like to start with toplink provider.
> 2) Criteria vs Named Queries: I am not convinced (yet) that Named
> queries are the way to go. I did some digging around, they are indeed
> best practices for JPA but I think the decision merits other
> consideration(s). I still believe the Criteria Queries will help us
> define a cleaner Store interface.
I'm always in favor of named queries.
An other point about them that I haven't explain in previous threads (I
think) is that with named queries, it is possible to modify queries
externally with xml files so if with a DB we have some performance issues,
it will be possible to override queries by a modified JPQL query or a native
query.
> 3) Using Criteria Queries would mean that we use JPA extensions
> specific to provider. I don't see this as an issue as long as we are
> not expecting underlying JPA providers to be swapped. Thoughts?
Continuum isn't a big application and I don't think we need provider
extensions for now.
Before to start the code, I'd like to see a DB model exported to an image so
we'll can include it in the site. We must define too which datas will stay
in the db and which datas will be externalized in some files.
>
> Look forward to hear.
>
> Cheers,
> Rahul
>