NoSQL datastore - review comments and ideas

[Jean-Sebastien Delfino <js...@apache.org>]

Hi Eranda,

I've reviewed your cassandra, couchdb and hbase implementations
yesterday. Great work!

I have a few comments and suggestions:

- I like your Session, Database, and Group interfaces, and how you've
defined common interfaces that seem to work well for the three stores.
I'd suggest to add overview comments at the top of the interfaces to
help people understand them without looking at the implementations.

- The static variable in SessionFactory doesn't seem to be used and
should be removed.

- I'd suggest to rename getValue to getEntry as you're using the term
Entry everywhere else, or change the other methods and use the term
Value everywhere... whichever you prefer.

- You have a mix of tabs/2/3/4 spaces in your code which makes the
indentation difficult to follow with a plain text editor or Web
browser. Typically we only use spaces. I personally use 4 spaces, but
I leave that for you to decide.

- I understand this is just a first cut of the code but I recommend to
cleanup the exception handling -- replace the prints by actual error
handling logic :) -- and perhaps define which exceptions your want to
surface to the caller.

- Test cases should be named *TestCase, be proper Junit tests with
asserts, and run as part of the Maven build without requiring
additional setup. This will help others in the project try out your
code and verify it works, and eventually run your tests in the
automated build.

- Your Maven pom.xml could inherit from a Tuscany parent pom. I'd like
some of the Maven experts on the project to give their input here, as
I've not touched Maven for a while and have already forgotten most of
it.

- Your addEntry method takes an Object value but then the
implementation casts it to String. What's your assumption w.r.t data
types here? If you're going to only support strings (which is OK by
me) then the interface should take a String. If not, then I guess you
need to investigate how other data types are going to be stored in the
database.

And a few more general questions and ideas:

- What is your next step now? Are you going to try to add another
store like the AppEngine datastore for example? or are you planning to
work on the next level of integration with actual SCA components?

- Did you look at the few REST examples in Tuscany? and do you have
any thoughts on how their interfaces will match / integrate with what
you have here?

- If you're going to just support string data (which again is OK by
me), what kind of data representation do you want to support in your
REST service? XML? ATOM? XHTML? JSON? All of these would make sense
and could be served depending on the HTTP Accept header presented by
the client, but you may want to pick one to start with...

- Are you planning to turn your twitapp into an assembly of SCA components?

-- 
Jean-Sebastien

Re: NoSQL datastore - review comments and ideas

[Eranda Sooriyabandara <07...@gmail.com>]

Hi Jean-Sebastian,
Nice to hear from you,


> - The static variable in SessionFactory doesn't seem to be used and
> should be removed.
>

I used to to make the SessionFactory singleton but I feel the same that
doesn't make sense to make it singleton. I'll make it.


>
> - I'd suggest to rename getValue to getEntry as you're using the term
> Entry everywhere else, or change the other methods and use the term
> Value everywhere... whichever you prefer.


> - You have a mix of tabs/2/3/4 spaces in your code which makes the
> indentation difficult to follow with a plain text editor or Web
> browser. Typically we only use spaces. I personally use 4 spaces, but
> I leave that for you to decide.


> - I understand this is just a first cut of the code but I recommend to
> cleanup the exception handling -- replace the prints by actual error
> handling logic :) -- and perhaps define which exceptions your want to
> surface to the caller.


> - Test cases should be named *TestCase, be proper Junit tests with
> asserts, and run as part of the Maven build without requiring
> additional setup. This will help others in the project try out your
> code and verify it works, and eventually run your tests in the
> automated build.
>

Yes I want to review the basic structure and in the tests that it works. I
will do the error handling part as well as the tests using JUnit and the
comment outs. About spacing 4 would be nice for me also.


>
> - Your Maven pom.xml could inherit from a Tuscany parent pom. I'd like
> some of the Maven experts on the project to give their input here, as
> I've not touched Maven for a while and have already forgotten most of
> it.
>

I can tried out this as well as If anyone can give me input for how to
inherit pom.xml from the  Tuscany parent pom that would be great and will be
faster.

>
> - Your addEntry method takes an Object value but then the
> implementation casts it to String. What's your assumption w.r.t data
> types here? If you're going to only support strings (which is OK by
> me) then the interface should take a String. If not, then I guess you
> need to investigate how other data types are going to be stored in the
> database.
>

Lets make it simple and use only String. When we do the further modification
we can add that option as well. I'll do the changes needed to make it
String.


>
> And a few more general questions and ideas:
>
> - What is your next step now? Are you going to try to add another
> store like the AppEngine datastore for example? or are you planning to
> work on the next level of integration with actual SCA components?


I am planning to integrate these codes with the actual SCA components and I
followed the REST example as well as the example described in the Luciano's
blog.

>
> - Did you look at the few REST examples in Tuscany? and do you have
> any thoughts on how their interfaces will match / integrate with what
> you have here?
>

I didn't workout with this. But I will let you know soon as my next task is
to integrate with REST.


> - If you're going to just support string data (which again is OK by
> me), what kind of data representation do you want to support in your
> REST service? XML? ATOM? XHTML? JSON? All of these would make sense
> and could be served depending on the HTTP Accept header presented by
> the client, but you may want to pick one to start with...
>

I thought JSON would be good. But since I am not familiar with them I cant
tell which one is most suitable. If you have any suggestion on this thats
would be great.


> - Are you planning to turn your twitapp into an assembly of SCA components?


Yes, we can use this as our test component and use as the scenario we can
describe the datastore components.

Thanks for your valued input.

thanks
Eranda