Hi all!

The project seems extremely interesting and I want to thank you for sharing it with the community.

I have a couple of questions:

1/ Will Shards work only with Hibernate 3.2 or is it possible to run it against 3.1 too?

2/ Objects With Ids That Are Base Types: although for the record, we prefer object ids because they make it easy to determine whether or not an object has had an id assigned.

Isn't the unsaved-value enough for dealing with the above?

3/ In the javadoc of ShardedSessionImpl, ShardedCriteriaImpl, ShardedQueryImpl there are a few deprecated methods. These are not part of the original interfaces, so I am wondering if this was an initial attempt to address some problems and they will be removed because they failed to really solve the problems they were addressing.

4/

Maybe some overloaded methods allowing to pass in the shard id? Like:

Criteria crit = session.createCriteria(Class<?> class, Integer shardId)

I have a couple of more questions related to shared data sharding, but I guess those would fit better another thread.

TIA,

./alex
--
.w( the_mindstorm )p.
_____________________________________
Alexandru Popescu, OSS Evangelist
TestNG/Groovy/AspectJ/WebWork/more...
Information Queue ~ www.InfoQ.com

Hi Alex, thanks for the questions. Let me see if I can answer them.

1/ Whether or not Shards can run using 3.1 depends entirely on how the Session, SessionFactory, Criteria, and Query interfaces changed between 3.1 and 3.2. It's been awhile, but I believe there were a couple of changes. If they were additive, you're fine. If signatures of existing methods changed, you're out of luck (unless you want to tweak the code and build your own version). There's nothing in the Shards code that depends on 3.1 versus 3.2.

2/ I need to confirm, but I'm pretty sure I fixed this in beta2 and forgot to update the docs. Dumb dumb dumb. I'll verify and get back to you. But yes, unsaved value is fine, if you like that sort of thing (I don't :-)

3/ The only methods that are deprecated in our impl are deprecated on the interfaces themselves. We need to provide implementations of those interface methods to get them to compile, but seeing as Hibernate Core intends to do away with them at some point we thought it was reasonable to not provide a sharded implementation in the first place.

4/ Yeah, we should definitely do what you're suggesting, probably along with:
session.createCriteria(Class<?> class, Set<Integer> shardIds);

The really useful one, however, is to make it easy to "lock" a session against a single shard so that all operations execute against just that shard for the rest of the session's lifetime (or until someone calls "unlock," assuming we decide to expose such a method). We already have something similar to this for saves and updates.

Please let me know if you have more questions.

Thanks,
Max

Update:
Objects with ids that are base types are fine, I simply forgot to update the docs. Filed a doc bug:
http://opensource.atlassian.com/projects/hibernate/browse/HSHARDS-41

Max

First of all thanks for answering.


I will check this and report back.



Thanks for the update. It is not a matter of my preference (I don't use those either), but once we can make it work why not :-).



I guess I need to be more explicit on this. I may be missing something but I see that even if ShardedSessionImpl implements org.hibernate.Session it also contains the deprecated methods from org.hibernate.classic.Session. So what's the relationship there?



Yep, that's it. This looks good.

As I mentioned in the other thread, I will have a couple of more questions (mostly about the missing features ;-) and possible approaches). But this is it for now.

many thanks,

./alex
--
.w( the_mindstorm )p.
_____________________________________
Alexandru Popescu, OSS Evangelist
TestNG/Groovy/AspectJ/WebWork/more...
Information Queue ~ www.InfoQ.com

I understand your question now, and I'm trying to remember why we made the ShardedSession interface extend org.hibernate.classic.Session instead of org.hibernate.Session. Nothing convincing is springing to mind, so hopefully I just goofed and we can change ShardedSession to extend org.hibernate.Session and get rid of the implementations of the deprecated methods altogether.

Thanks,
Max

Well, the published javadoc is just confusing [1]:

ShardedSessionImpl implements org.hibernate.Session,[...], org.hibernate.shards.session.ShardedSession

Then at [2]

ShardedSession

All Superinterfaces:
Serializable, org.hibernate.Session

but later:

public interface ShardedSession
extends org.hibernate.classic.Session

As far as I know org.hibernate.classic.Session extends org.hibernate.Session. I am wondering what am I missing?


Also, Max Rydahl's comment on the JIRA issue is confusing: if classic.Session is meant for Hibernate2, then I see no reasons for keeping it around in Shards. Or is it again something I'm missing :-) ?

bests,
./alex
--
.w( the_mindstorm )p.

[1] http://www.hibernate.org/hib_docs/shard ... nImpl.html
[2] http://www.hibernate.org/hib_docs/shard ... ssion.html

After some more thinking I think I got it: classic.Session was meant to ease the migration of apps using Hibernate2 to Hibernate3, so this may be currently in use.

The other part still holds (I hope :-) ).

./alex
--
.w( the_mindstorm )p.

I've checked out the code and now things are more clear :-).

./alex
--
.w( the_mindstorm )p.

To sum it up even more succinctly, the SessionFactory interface still returns classic Session. If ShardedSession didn't extend the classic Session interface we wouldn't be able to have a sharded SessionFactory implementation.

Max