yeah, using Git as back end storage is very interesting, is there already code i can follow? ------------------------- Best Regards,
Strong Liu <stliu at hibernate.org> http://about.me/stliu/bio On Apr 2, 2012, at 11:14 PM, Sanne Grinovero wrote: >> >> (2) Git (used as a versioned key-value store, based on jgit). I know >> it might sound a bit crazy but I'm using jgit as an embeded, versioned >> key value store. It works great in situations where: >> >> a) most of the content stored is text-like and strict versioning / >> history is needed >> b) a storage is mostly-read (I mean, there are far more reads as >> compared to writes) >> >> So it is really cool in situations like CMS / WIKI where content >> versioning / auditing is stricly needed. Combine it with OGM + >> hibernate search and you get a very interesting data storage. > > Very surprising, but very interesting as well. you're right, there are > excellent use cases, and Git + Search is a perfect match for them. > > You're not thinking of branches and similar, right? > > Have you heard of Hibernate Envers ? Sounds like - in the long term - > it should expose the same APIs, as it mostly provides auditing. > > >> Now, for the jgit-backed storage there is no JTA support (althought >> people were thiniking about it: >> http://git.661346.n2.nabble.com/Any-plans-to-support-JTA-and-XA-in-jgit-td1495190.html) >> but from my knowledge of jgit it would be relativelly easy to >> implement (having concurent transactions would be next to impossible >> but this is not a use case I'm targetting here - sequential >> transactions would be fine for rare-write use case like CMS). >> >> So once again, given the above idea of intgrating git storage, the >> transactional behaviour would look like this: >> >> 1) on transaction's start I would rember a git's commit id and create >> an in-memory git index (easy with jgit); >> 2) any operation inside of a transaction would write objects to git's >> repo + update in-memory index; >> 3) on transaction's commit I would simply create a new commit in git >> and move rev pointer to this new commit (here is the place were it is >> very easy to detect any concurent modifications); >> 4) transaction's rollback is trivial - I would just drop the in-memory >> index (git object written to a git database would be removed during a >> standard cleanup / garbage collection of a git repository). > > Sounds like an interesting plan.. but until we see the details it's > hard to see what might fail in this. > >> Given the above it wonder if I should take a route of implementing an >> XAResource for jgit or maybe there is another place in OGM I could >> plug into to be notified on transaction's start/commit/rollback. > > If you where to implement XAResource for jgit, that might be nice for > other projects needing it. > It also sounds like the better abstraction for OGM, since as mentioned > we currently hope to avoid needing > to manage these details. > >>> Some NoSQL databases support JTA, for example both EHCache and >>> Infinispan do participate in JTA transactions; for this reason the >>> currently supported databases by Hibernate OGM have JTA "for free" and >>> you don't find much code about it (other than binding JTA). >> >> Yes, I see. Digging more into the EHCache and Infinispan >> implementation at the moment to make sure that I understand all the >> details. >> >> Thnx for your input so far, it would be also interesting to know if >> other people would be interested in a such versioned key-value store. >> It works perfectly for my particular use case but I wonder if others >> would be interested as well. > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
