gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lewis John Mcgibbney <lewis.mcgibb...@gmail.com>
Subject Re: Apache Gora March board report (draft)
Date Wed, 07 Mar 2012 15:05:57 GMT
OK so Board report is submitted and Committed @ revision 33866.

I think we should progress with replacing offending method's/code in
SqlStore with TODO's. This will mean that we can spin a 0.2 RC and put it
to bed.

Development can continue towards 0.3 with a gora-sql re-write, then
addition of the gora-accumulo, gora-dynamodb, and possibly (hopefully) the
gora-solr modules. This would make good logical sense and also shows the
incremental strategy we are moving towards to make the Gora framework a
better piece of software.

What do you guys feel about addressing GORA-78 as per above, then knocking
back the remaining issues which can be addressed under 0.3?


On Tue, Mar 6, 2012 at 5:59 PM, Lewis John Mcgibbney <
lewis.mcgibbney@gmail.com> wrote:

> OK then.
> On Tue, Mar 6, 2012 at 3:55 PM, Mattmann, Chris A (388J) <
> chris.a.mattmann@jpl.nasa.gov> wrote:
>> One option is simply to remove the sqlbuilder library
>> and to replace SqlStore with stubbed out methods that throw Exceptions
>> and that simply don't work. Then we ship Gora 0.2, with a note saying
>> don't use SqlStore.
> +1 I will get this sorted out shortly subject to other comments that come
> through in the interim.
>> Then if folks complain and want to use it, we ask that
>> they help to write the method implementations using an ALv2 compatible
>> library.
> yep
>> Would Derby be useful here, or Hypersonic SQL? Both of those
>> are ALv2 compatible I think.
> Well the benefit of rewriting the gora-sql module to utilise JOOQ was that
> it would provide a common interface which supported many underlying sql
> store implementations. The reason that the specific DDL statements which we
> require are not currently implemented in JOOQ is that Lukas has not been
> able to identify a common way of doing this in the framework yet. I think
> it is beneficial for us to aspire to have a great gora-sql module, but it
> is not good for this to block a release, especially as most of us are not
> using this module, and of course the fact that we have witnessed some
> excellent work going into the Gora framework elsewhere.
> Implementing your suggestion as above would leave us with no blockers (in
> my opinion) to getting an RC rolled out.The quicker we can get more people
> using Gora the better.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message