Looked briefly at Shards today, I have the following questions (I am hoping that one of the Shards developers might respond)

1. Could Shards provide a suitable solution for my problem, which can be summarized as follows:
I am implementing a "Publish" semantic, whereby a complex object graph is to be published (e.g. replicated) on demand
from an internal environment to an external environment. The object schemas and relationships are not concrete at this stage,
so I am wondering if Shards could provide a simpler solution than developing and maintaining a custom database replication
implementation (e.g. trigger + stored procedure)

2. What is the anticipated "post Beta" release date for Shards?


Thanks,

Steve E.

Hi Steve,

Congrats on posting the first Shards question!

Regarding 1:
In the short term, definitely not. It sounds like you need vertical partitioning, and while we can think of a bunch of useful features in this area we really want to get the horizontal side of things running smoothly before we start implementing any of them. Medium term, I think support for object-level (or more likely, object graph level) replication strategies makes a lot of sense. The problem is easier for read-only/slow changing data than for what we would call transactional data, so we'll probably tackle that first.

Regarding 2:
We don't have a date and at this point aren't in a position to offer one. We really want to see how many bugs get shaken out as people start to tinker, and we also need to fill in the implementations for a couple of important methods in the API.

Just saw shards today, and am pretty excited.

My team currently has been working with cross-shard object graphs (I've bought into the terminology already) for a while doing custom extensions with hibernate and alot of interceptor and collection management work.

We'll try and plug shards in to handle the graphs in a single shard this next week, and meld it with our own cross-shard work.

This is extremely exciting.

Is the issue tracker still the place of choice for various random feedback or will shards be setting up special forums/lists soon? Typically i like only sending patch format stuff to jira issue trackers.

Once again, extremely exciting.

Great, glad you're excited. The cross shard work sounds exciting. I'm curious, have you been able to make it work without modifying Hibernate Core? Our assumption has been that we would need to dig deeper than interceptors and custom collections in order to make it work but it would be great to hear if that wasn't the case for you.

Regarding forums/issue trackers:
Our plan is to try and do things the same way the other Hibernate projects do things. Is there something else that you think would work better?

Thanks,
Max

Working with Shards a few days now, I am really surprised how good it is already working.

Think I found a litte bug in ShardedQueryImpl.setMaxResults.

I make a query like this:




The list contains 3 person objects. One from every configured shard. That's not what I would expect?!

setFirstResult seems to behave correctly.

// Edit:
For criteria query there is no problem. Too bad I cannot use it, because I need property projection which is unsupported in the moment.

Glad that things are going well so far.

That does indeed look like a bug, hopefully simple to fix. Would you mind filing it in JIRA?

http://opensource.atlassian.com/project ... board.jspa

Thanks,
Max

today i looked at the Shards and i'd like to put a question. I need find way to access data in two DB by using Hibernate. From one DB i will only read data, from another - write data. Replication will be organized by means of concrete DB.
Can the Shards lib be helpful for me?

Thanks in advance

Hi Igor,

We don't currently have any built-in support for replicated data. Adding replicas that get hit for your read-only operations can be a nice way to scale your database tier, but your application code typically needs to know whether an operation is going to be a read or a write so it can choose which datasource to use. That said, you could use shards if you did something like the following:

Create a ShardSelectionStrategy that always chooses your master.
Create a ShardResolutionStrategy that consults some globally available (presumably thread-local) value indicating whether the current request is a read or a write. If the current request is a write, the resolution strategy returns the id for the master db. If the current request is a read, the resolution strategy returns the id for one of your replicas.

Of course this doesn't buy you very much. You're going to need to set some flag at the beginning of every operation, and if you just initialized 2 SessionFactories explicitly with the same mappings the work you do to set the flag isn't really any different than the work you'd do to choose which SessionFactory you want your Session from.

Hope this helps,
Max