Welcome!

5 views
Skip to first unread message

Guillaume Laforge

unread,
Mar 26, 2010, 3:08:54 AM3/26/10
to Inconsequential
Hi all,

We've all more or less already discussed the topic together, but I
wanted to greet you all here on this group, so as to start some
fruitful discussions and collaboration! Welcome!

So this discussion group is about the "Inconsequential" project. That
could even be spelled "iNcOnSeQuenciaL", to echo the famous NoSQL
acronym.
The project is currently living under the Grails umbrella right now,
as our initial goal is to allow access to various kinds of NoSQL
datastores with a common API, from Groovy and Grails project, as well
as, hopefully, classical Spring and Java projects.

The codebase is living on GitHub in the Grails repository:
http://github.com/grails/inconsequential

It's currently exclusively developed in Java, in hope for it to be
usable easily from pure Java projects without mandating the use of
Groovy.
But ultimately, the idea is to make the API as Groovy-friendly as
possible, and provide a particular module for Grails so that we can
use the Grails ORM mapping solution and map domain classes on top of
those base APIs for the various datastores.

Basically, there will somehow be two main subprojects:
1) the base API for accessing the datastores (all the low-level
operations, etc)
2) the mapper API for being able to use GORM syntax, relationships,
etc, for mapping domain classes to datastore entities

There's not much code so far, just a sketch of the various interfaces,
and some more code for the Key/Value datastore approach, with a test
base using the Google App Engine datastore.

After some discussions with our friends from Neo4J, I've made some
refactoring, to move things into the KeyValueDatastore interface
rather than keeping things in the base Datastore interface.
I've also added minimal transactional support this morning --
wondering whether we should just go with the usual JTA interfaces
directly?

I just saw this morning that Tobias has forked Inconsequential on
GitHub and started working on the Graph datastore, that's really
awesome, and I'm very happy to see that -- unfortunately, I haven't
yet looked at all at the code, but I promise I'll do so soon!

Speaking of contributions, we'll certainly have to make contributors
sign an agreement with SpringSource, ie. the Individual Contributor
License Agreement (https://support.springsource.com/legal/individual-
cla and here: http://service.springsource.com/download/committer_agreement/agreement.pdf),
so that we're all safe with regards to IP, copyright, licenses, usage,
and so on. Unfortunately, I'm not a lawyer, but I'll do my best to
answer any question regarding this (forwarding to those who know
better than me!).

What else... hmmm... I need to provide a proper build for the project,
proper dependencies listed, etc.
And well, we need to move forward with sketching the various
interfaces for the various possible stores.

I'm happy to discuss API design and more with you all, that's very
exciting and interesting!

Thanks a lot for your contributions and mindful comments!

Guillaume

Tobias Ivarsson

unread,
Mar 26, 2010, 10:54:04 AM3/26/10
to inconse...@googlegroups.com
Since you brought it up I thought I'd share what I've done in the branch I created of this project.

1. I've added maven build information to the project. This enabled me to do automatic builds and automatic testing on our (Neo Technology's) hudson server.
2. I've created a Neo4j implementation of Datastore.
3. I've extended the GraphDatastore interface to allow for basic graph crud operations. Later on I would like to add support for graph traversal as well, but I think this should be use case driven, so we should probably start moving up the stack pretty soon and get Grails to use our abstractions.

I've used git submodules for the Neo4j implementation in the branch I made, this enables us to separate the interface (the inconsequential project) from the implementation (the neo4j-inconsequential project and others to come), so that we can maintain proper project ownership: the inconsequential API being owned an maintained by the Grails community and the Neo4j implementation of this API being maintained by the Neo4j community.

I think we could pull back the changes from the branch I made and I could continue working on the Neo4j implementation of the API without having to be granted write permissions to the official inconsequential repository. But while we are working on the API it makes sense for me to maintain a branch, since I will probably have ideas and suggestions to changes to the main inconsequential stuff, and a branch is a good way of maintaining those things.

Moving straight on to what ideas and suggestions I have at the moment:

* I really like the recently added beginTransaction() method in Context and the createContext() method in Connection, that's the perfect place for these methods.
* I'm not sure how useful the set{Transaction,Connection,Session} methods are. When are these needed? Perhaps it would be better to either have them be protected (rather than public) or let the get{Transaction,Connection,Session} methods be abstract.
* There are a lot of inconsistencies in the use of generics.
  * Transaction is a generic class now, but the methods for creating and getting the transactions don't return generic versions. I'm not sure we really need a getNativeTransaction() method on the Transaction class, this could be an implementation detail.
  * Likewise I don't think we need a getNativeKey() method on the Key interface, I think it would be better to have the methods on the KeyValueDatastore (and my GraphDatastore) accept and return an implementation specific subclass of Key. (see Listing 1)
  * The 'object' parameter to KeyValueDatastore.store(...) should be Map<String,Object> (I sneaked this into Listing 1 as well).

Listing 1:
// Suggested modification of KeyValueDatastore to use implementation specific subclasses of Key
public interface KeyValueDatastore<K extends Key> extends Datastore {
    public K store(Context ctxt, String table, Map<String,Object> object);
    Map<String,Object> retrieve(Context ctxt, K key);
    // ... etc ...
}


Cheers,
Tobias Ivarsson

To unsubscribe from this group, send email to inconsequential+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.



--
Tobias Ivarsson <tobias....@neotechnology.com>
Hacker, Neo Technology
www.neotechnology.com
Cellphone: +46 706 534857
Reply all
Reply to author
Forward
0 new messages