A Groovy Way to Use an H2 In-Memory Database

The H2Project

https://github.com/jnorthr/H2Project

This is a short sample Groovy class with some tests to try out the H2 in-memory database feature.

Just wanted to give you a starting point to try the H2 in-memory database. I’ve used the Groovy development language here to setup a set of methods. The whole class named H2 is constructed in the style of a java class with all it’s syntax. Ok, it’s not exactly a java program. For that you would need to add more syntax.

For this demo, i’ve tried to use the most common features of the H2 grammar.

Project Layout

This project is arranged in a folder structure that’s compatible with many build systems. In this demo, i’ve used the gradle build tool. Have also included a full gradle wrapper with required bits and pieces the code needs to work correctly. These are declared within the build.gradle script.

Folder Layout

• * build.gradle – the script gradle uses in the build process
• * gradle.properties – influences the gradle build tool
• * License – what you can/cannot do with this project
• * README.md – this text file
• * build/ – a folder of all the pieces constructed when you do a gradlew build command
• * gradle/ – everything needed to make gradle run on your system without installing gradle; Gradle will self-install any missing jars, code, scripts, etc if your system is connected to the internet the first time you do a gradle build command
• * src/
• * /src/main/groovy/com/jnorthr/H2.groovy – the only bit of code with samples of what can be done when working with the H2 database
• * /src/test/groovy/com/jnorthr/H2Tests.groovy – a series of self-testing methods to confirm the H2.groovy class is running correctly.

H2 Syntax

The H2 Grammar is described here : http://www.h2database.com/html/grammar.html

Bash shell script to make another git repository project

Overview

You will need to be using an apple mac or ubuntu linux system to gain the most from this script. It should be possible to do this in windows, but as i do not have one, i can’t advise. The commands shown here are trial commands keyed into a terminal session running the bash shell. It assumes you have already followed part one of this guide to make a github repository named ‘sample’ on your github account.

The idea is to use bash commands to control a remote github system holding your repository. Comment lines below are preceded by double // characters, these lines are remarks that must NOT be keyed. Further comments may follow a command and you can tell these by looking for <–

You will also need the ‘git’ tool installed on your local system.

Note that the term ‘repo’ is a short term for repository – a storage area, typically for text, documents and source code.

// ————————————————–
// new script to make another git repository project
// go to github and make a repository called sample // you will need an SSH public/private security id set up in your keychain – google for this uif you do not already have a set of public/private SSH keys.
// http://blog.blindgaenger.net/generate_github_pages_in_a_submodule.html

// Create a new project here….
// change into the directory of your choice on your local system
cd /Volumes/Media1/Software

// here i ask the remote github server for a full copy of my sample repository that i made in part one of this guide.
// the clone command will create a folder directory named ‘sample’, create some local metadata that git needs to function, and also create an alias name called ‘origin’. This alias name is just a short-cut way to avoid writing the full address of our git repository, like git@github.com:jnorthr/sample.git !
git clone git@github.com:jnorthr/sample.git

// change into the cloned folder
cd sample

//git init

// create an empty file for some of our documentation.
touch README

// edit and save some notes about this project – apple macs use the open command to start an editor session, forgot the ubuntu equivalent command
open -e README

// now we tell the local version control system, git in this case, to include the README file as an artifact to be controlled by git
git add README

// and we tell git that we are ready to mark the current environment as ready-to-go
git commit -m "initial commit"

// if you run git clone above, you will not need this command
git remote add origin git@github.com:jnorthr/sample.git

// time to tell git to send a full copy of our environment back to the github server for user github.com:jnorthr and specifically for the storage facility named sample.git :
git push origin master

// we can construct a documentation area within our ‘sample’ repository. By default, this area is named ‘gh-pages’
// Create an own branch for the gh-pages
cd sample


git symbolic-ref HEAD refs/heads/gh-pages
rm .git/index
git clean -fdx

// build a small index page, we can expand this later
echo "Hi Kids" >> index.html

// tell the local version control system to include all files, etc in the current directory named ‘.’
git add .

// and we tell git that we are ready to mark the current documentation as ready-to-go
git commit -a -m "my first gh-page"

// and here we send our whole document environment to the github server
git push origin gh-pages


// The index.html is empty. But it’s necessary to commit something to make the branch live. If not, you’ll have problems on the next step.

Check page online

Alright, after pushing your files you’re ready to check out the generated site online at an address like http://jnorthr.github.com/sample/
where you replace my name with your github account name, and replace the name ‘sample’ with the name of the repo you built in part one of this guide.

. . .

i’m still working on this section of code as it does not work well just now, so would suggest you stop here and just review the code and links below.

// Add documentation as a submodule in master branch

Now we have two branches called master and gh-pages. The next step is to point the reference for the gh-pages branch to a subdir of master. See http://git-scm.com/book/en/Git-Tools-Submodules

Our submodule will then appear to be part of our hosted project at github.

git checkout master
git submodule add -b gh-pages git@github.com:jnorthr/sample.git _site
git status
git commit -m "added gh-pages as submodule"
git push

Git status reports a new .gitmodules file, with metadata about the submodules. And the _site directory we just specified. Now we initialize the sub-module and confirm it’s version:

git submodule init
git submodule
git status
cd _site
echo "Index Page for _site" >> index.html
git add .
git commit -m "site generated"
git push origin gh-pages
cd ..


// so back at root of project, commit again
git commit -a -m "build site"
git push origin master


// Now both branches should be pushed to github and master _site points to the up to date gh-pages as we would normally do.

Sequence of Steps to Build a New Github Repository

Overview

..

Here is your view of github. You will see this display when you have successfully logged into github. It’s an overview of your code repositories. There is a green button at lower right marked ‘New Repository‘. Click that to start the process to make a new storage repository for the new project.

..

..

This panel will appear. The repository name should be short and sweet – not too long. Try ‘sample’ as a name. A description is also useful and will become part of the documentation, so choose wisely. Click the green button marked ‘Create Repository‘. See next image.

..

The basic project has been built on the github server. We can also ask for the automatic generation of a small amount of documenation. Look for the ‘Settings‘ choice at the top right of the menu bar. If we click that, it opens the following page.

..

..

..

Ok, we can choose some settings here. The ‘Automatic Page Generator‘ button at the lower right of this panel allows us to have some documentation made for us.

..

..

..

..

A skeleton page of text is generated. Here we can make changes and improve the text and information for our project. Click the green button marked ‘Continue to Layouts

..

..

..

This panel offers us a preview of what our generated documentation might look like. We also have the opportunity to change the color theme in which our documents are displayed. Click each of the little thumbnail images at the top of this panel to see the effect on the document page, or see that small grey right-arrow button to the right of those thumbnails ? Click that to reveal even more themes. When you’ve made your selection of a theme, you can publish the documentation by clicking the green checkmark at top right of this panel.

..

..

After clicking the publish button, this panel reappears to show us the content of our respository with the newly made assets of our documentation. Note the blue box that shows the website address of this new documentation as ‘Your project page has been created at…’ with an address after that. If you copy that address into your favorite browser and send it you will be greeted with a custom panel of documentation for your project.

* * *

In part two of this writeup, we’ll look into some of the ways we can use scripted commands to construct a github repository.