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? Thanks On Tue, Mar 6, 2012 at 5:59 PM, Lewis John Mcgibbney < [email protected]> wrote: > OK then. > > On Tue, Mar 6, 2012 at 3:55 PM, Mattmann, Chris A (388J) < > [email protected]> 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. > > > -- *Lewis*
