Skip to content

Latest commit

 

History

History
60 lines (40 loc) · 3.66 KB

CONTRIBUTING.md

File metadata and controls

60 lines (40 loc) · 3.66 KB
Raw

Contributing to Honeycomb

Want to contribute to Honeycomb? Here's how you can help.

Reporting Issues

Bug reports and feature requests can be submitted to our GitHub issues tracker. In the case of a bug report, the following information is necessary for us to track down bugs:

  • system information - including operating system and version, MySQL version, Honeycomb version, and Java version
  • a reproducible test case - where possible this should include the SQL commands which recreate the issue (including commands to create any involved tables).
  • log output from honeycomb-c.log, honeycomb-java.log, and your MySQL error log.

Pull requests

We accept pull requests to the Honeycomb GitHub repository. Please keep in mind the following when submitting pull requests:

  • include a clear description of why the changes are necessary and what has been changed
  • where possible, include unit tests covering the changes, preferably that failed pre-change
  • commits should be as self-contained as possible, with useful messages
  • pull requests should rebase cleanly against the develop branch

Branches

  • the master branch holds the latest release version of Honeycomb.
  • the develop branch stages all changes to be included in the next release.

Coding standards

C++

Public functions/methods and non-obvious private methods should have Doxygen style documentation. C/C++ code should conform to the following the style guidelines (if not specified below defer to the Google C++ Style Guide):

  • opening braces on own line
  • two space indent
  • UpperCamelCase for class names
  • snake_case for variable names
  • SCREAMING_SNAKE_CASE for macros

Java

Public methods and non-obvious private methods should have JavaDoc style documentation. Java code should conform to the following style guidelines:

  • opening braces on same line
  • four space indent
  • UpperCamelCase for class names
  • lowerCamelCase for variable names
  • SCREAMING_SNAKE_CASE for constants

Exceptions

Honeycomb spawns a JVM inside a native process without exception handling, so catching and dealing with Java exceptions can be complex. The guidelines below describe how and where Honeycomb throws and handles exceptions:

  • The barrier for checked exceptions is between the interfaces Store, Table, and Scanner. All exceptions coming out of those interfaces must be RuntimeExceptions.
  • Exception logging should happen as close to the source as possible, with logging containing maximum detail, including source, reason, and stack trace. Log the context of the operation that caused the exception to occur.
  • Typed runtime exceptions should only be added if they enable better error handling / recognition on the C++ side. I.E. a typed runtime exception should only be added if it translates to something other than a generic HA_ERROR code.
  • IOExceptions should be wrapped in RuntimeIOException, which indicates to the C++ side an IOException occurred.
  • Uncaught exceptions will bubble up to the C++ side and be caught and reported there. Runtime exceptions of certain types will be handled specially (TableNotFoundException, RowNotFoundException, etc.)
  • Every JNI call must check the JVM for exceptions upon return.

cluster