I am not really sure if putting isMaxStackSize in pilad/config.go is the best way, feel like check full should be encapsulate in the stack itself.

I am open to suggestion.

Description:

    Add a new rest endpoint FULL which checks if a particular stack is full or not.

Testing Methodology:

    Verify the following curl call to full will return full = true

        ./bin/pilad -max-stack-size 0
        curl -XPUT "localhost:1205/databases?name=MY_DATABASE"
        curl -XPUT "localhost:1205/databases/MY_DATABASE/stacks?name=BOOKSHELF"
        curl -XPOST localhost:1205/databases/MY_DATABASE/stacks/BOOKSHELF \
            -d '{"element":{"title":"1984","author":"George Orwell","ISBN":"1595404325","comments":[]}}'
        curl "localhost:1205/databases/MY_DATABASE/stacks/BOOKSHELF?full"

    Verify the following curl call to full will return full = false

        ./bin/pilad -max-stack-size 2
        curl -XPUT "localhost:1205/databases?name=MY_DATABASE"
        curl -XPUT "localhost:1205/databases/MY_DATABASE/stacks?name=BOOKSHELF"
        curl -XPOST localhost:1205/databases/MY_DATABASE/stacks/BOOKSHELF \
            -d '{"element":{"title":"1984","author":"George Orwell","ISBN":"1595404325","comments":[]}}'
        curl "localhost:1205/databases/MY_DATABASE/stacks/BOOKSHELF?full"

Hi fern4lvarez,

This pull request fixes the code reviews from https://github.com/fern4lvarez/piladb/pull/65

1. Pull request merging to dev-0.2 instead of master
2. change handler and api name to empty to conform naming convention
3. Implement Empty function in stack.go
4. Enforce 100% code test coverage.
5. Allow maintainer to edit pull request.

Description:

Added isEmpty functionality to api. Now client can access is_empty rest call to
determine if the stack associated to the pass in stack id and db id is empty or not.

Testing Methodology:

Verify the following curl call will return is_empty = false

    curl -XPUT "localhost:1205/databases?name=MY_DATABASE"
    curl -XPUT "localhost:1205/databases/MY_DATABASE/stacks?name=BOOKSHELF"
    curl -XPOST localhost:1205/databases/MY_DATABASE/stacks/BOOKSHELF \
        -d '{"element":{"title":"1984","author":"George Orwell","ISBN":"1595404325","comments":[]}}'
    curl "localhost:1205/databases/MY_DATABASE/stacks/BOOKSHELF?is_empty"

Verify the following curl call will return is_empty = true

        curl -XPUT "localhost:1205/databases?name=MY_DATABASE"
        curl -XPUT "localhost:1205/databases/MY_DATABASE/stacks?name=BOOKSHELF"
        curl "localhost:1205/databases/MY_DATABASE/stacks/BOOKSHELF?is_empty"

Verify that empty db or stack will have standard empty response

In particular, Peek could panic, but this doesn't prevent all race conditions (see commit msg).

IMO, the stack should just embed a mutex so that the client can decide whether or not to acquire a lock.

Hi fern4lvarez,

I am not sure if you are looking for contributors, but I saw your post on r/golang and got interested in the project. I saw issue New Stack operations #44 and decide to take a stab on one of the sub task. If you are cool with having contributors I will be happy to finish some of the other issues too.

Description:

Added isEmpty functionality to api. Now client can access is_empty rest call to
determine if the stack associated to the pass in stack id and db id is empty or not.

Testing Methodology:

Verify the following curl call will return is_empty = false

    curl -XPUT "localhost:1205/databases?name=MY_DATABASE"
    curl -XPUT "localhost:1205/databases/MY_DATABASE/stacks?name=BOOKSHELF"
    curl -XPOST localhost:1205/databases/MY_DATABASE/stacks/BOOKSHELF \
        -d '{"element":{"title":"1984","author":"George Orwell","ISBN":"1595404325","comments":[]}}'
    curl "localhost:1205/databases/MY_DATABASE/stacks/BOOKSHELF?is_empty"

Verify the following curl call will return is_empty = true

        curl -XPUT "localhost:1205/databases?name=MY_DATABASE"
        curl -XPUT "localhost:1205/databases/MY_DATABASE/stacks?name=BOOKSHELF"
        curl "localhost:1205/databases/MY_DATABASE/stacks/BOOKSHELF?is_empty"

Verify that empty db or stack will have standard empty response

Before this fix, if you tried to PUSH an element using some of the following payloads:

• {"elent":8}
• {"foo":8}
• {1:8}

The server wouldn't complain when parsing them, and would store a null on top of the Stack. Same behavior when trying to set some config value.

With this fix, we now check that the payload contains the word element as key. Otherwise, we return an error when decoding it, that will become a 400 Bad Request in pilad.

This commit does not imply API breaking changes, so it can be added in the next 0.1.X release.

Now it is possible to create a pila.Stack using a custom implementation that satisfies the stack.Stacker interface, e.g.

type TestStack struct{}

func (s *TestStack) Push(element interface{}) { return }
func (s *TestStack) Pop() (interface{}, bool) { return nil, false }
func (s *TestStack) Size() int                { return 0 }
func (s *TestStack) Peek() interface{}        { return nil }
func (s *TestStack) Flush()                   { return }

stack := pila.NewStackWithBase("stack", time.Now(), &TestStack{})

It is also possible to create a Stack with a custom base implementation from a Database instance:

id := db.CreateStackWithBase("stack", time.Now(), &TestStack{})

We replace our old UUID implementation, which wasn't RFC 4122-compliant and use the Version 5 of https://github.com/satori/go.uuid, which is lightweight and well tested. This dependency is added to our vendor directory.

This PR doesn't change the logic of piladb, only the way the Stacks and Databases UUIDs are represented.

Previously (0.1.X), when a Stack is full, PUSH operation is unavailable, returning 406 NOT ACCEPTABLE.

This change provides a new config value, of boolean type:

• PILADB_PUSH_WHEN_FULL as environment variable.
• -push-when-full as CLI parameter.

When this value is set to true, PUSH operations on a full Stack will be accepted, removing the bottommost element from the Stack.

This PR also adds a new Sweep method to the Stack, which will remove the bottommost element from the Stack, returning such element and an OK if it was successfull. Note that the method is implemented at the Stack level, but there's no such SWEEP operation from the outside of a Pila.

Fixes #42

• Add new script to execute tests on TravisCI gathering all coverage reports in one file.
• Update TravisCi file in order to execute this script and send data to codecov.io.
• Add codecov.io badge to README.
• Update README regarding code coverage.

This can be disabled by using the -no-donate command line flag, or setting PILADB_NO_DONATE environment variable to true.

This PR also introduces a new ASCII logo for the startup:

   .___.            _  _             _  _     
  /  _  \    _ __  (_)| |  __ _   __| || |__  
 |  |+|  |  | '_ \ | || | / _` | / _` || '_ \ 
 |  |-|  |  | |_) || || || (_| || (_| || |_) |
  \.___./   | .__/ |_||_| \__,_| \__,_||_.__/ 
            |_|   

Previously, when running a pilad server and then terminating it, it stopped immediately without caring about on-going connections.

With this change, whenever pilad server receives SIGINT or SIGTERM signals, it will wait for on-going connections until they are finished. If the connections aren't finished after the Shutdown Timeout is due, they all will be interrupted and the shutdown will happen.

This Shutdown Timeout can be configure with the pilad command with the -shutdown-timeout parameter, which value is 15 seconds by default. As other config values, it can be set on runtime using the /_config endpoint.

Add a prod Dockerfile for pilad with only 3 layers and weighting 11.2 MB. Also add DockerHub badge for /r/fern4lvarez/piladb in case of switching from dev image to prod image.

Version control will be the way piladb persists its contents: instead of writing data into disk, it will decode all atomic operations into a binary log, that will contain the history of the piladb server. This will make possible to recover the state of a piladb instance from a file in order to implement #14, and also to share the state with other instances in a distributed fashion, so we can achieve #13.

piladb needs proper documentation.

The chosen approach is to use GitBook, as it provides Git/Github compatibility, Markdown, well structured sections, nice user interface and possibility to export to PDF, Mobi or ePub.

The project will be called docs.piladb.org.

GitBook site: https://www.gitbook.com/book/fern4lvarez/docs.piladb.org Github repository: https://github.com/oscillatingworks/docs.piladb.org