> you sort of imply Slice does that while Shards does not.
I do not. If my words carry that implication, my sincere apologies. (I
will post this clarification in Serverside as well)
As I said, I am inspired by Hibernate Shards to work on Slice.
> for iii, it's more than Shards does not care at all and lets JTA do it's job
What happens when no JTA transaction manager in the environment? e.g.
in JPA parlance, a persistence unit with transaction-
type=RESOURCE_LOCAL
> Other question, do you deal with group by, having and aggregation?
Not yet. Slice is at version 0.4.0. Unique result aggregation can be
accomplished with the current approach of merging results from
different sources, but sorting /group by / having all are in
conceptually difficult domain right now. How about Shards on this
account?
On Jan 9, 5:54 pm, Emmanuel Bernard <o...@emmanuelbernard.com> wrote:
> nice,
> I saw one of your reply on TSS:
> "ii) Slice is based on OpenJPA (
http://openjpa.apache.org) as JPA
> runtime. Given my association with OpenJPA (am a committer), I could
> provide some user-friendly features. For example, data distribution
> policy is only to be specified for newly persistent object graph
> roots. The instances loaded via query or find() are tagged with the
> original database automatically.
> iii) Slice also provides two-phase commit across the slices provided
> the underlying database resources are XA-complaint. "
> you sort of imply Slice does that while Shards does not. Actually
> Shards does ii and iii as well (for iii, it's more than Shards does
> not care at all and lets JTA do it's job).
> Other question, do you deal with group by, having and aggregation?
> On Jan 9, 2008, at 01:01, pinaki.pod...@gmail.com wrote:
> > Hello,
> > Inspired by Hibernate Shards, I have developed Slice -- a
> > distributed persistence for JPA based on OpenJPA.
> > http://people.apache.org/~ppoddar/slice/site/index.html
> > Your comments and feedback are most welcome.
> > Regards --
