Re: ContinuumStore refactoring
As I already explained, I'm in favor of named queries On Fri, Feb 22, 2008 at 2:54 AM, Rahul Thakur [EMAIL PROTECTED] 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
Re: ContinuumStore refactoring
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
On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur [EMAIL PROTECTED] 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
