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<
[EMAIL PROTECTED]> 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<[EMAIL PROTECTED]>
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<
[EMAIL PROTECTED]>
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
<[EMAIL PROTECTED]> wrote:
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
