Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for SQLite #43

Closed
wants to merge 3 commits into from

Conversation

nathanweeks
Copy link
Collaborator

PASA is difficult to run on an HPC cluster due to the MySQL requirement. As an alternative to rearchitecting PASA to completely remove the dependency on a relational database, adding support for SQLite could involve much less development effort and provide enough capability/compatibility to run on most such systems (assuming, e.g., that the SQLite database isn't placed on a Lustre file system that has been mounted with noflock to disable file locking).

To get the ball rolling, I've done a minimal SQLite port that at least seems to be enough for run_sample_data.pl to complete without error. To use SQLite, in the pasa_conf/conf.txt file, set:

MYSQLSERVER=SQLite

Then the MYSQLDATABASE parameter is used as a pathname to an SQLite database. A few caveats:

  • The results of run_sample_data.pl haven't been compared with the results vs. when MySQL is used
  • Web UI is completely untested
  • The schema has been minimally translated from MySQL, with a few perhaps-unnecessary CHECK constraints in lieu of (unsupported) unsigned integers in random places.

Single quotes for strings, CURRENT_TIMESTAMP instead of now(),
and INSERT INTO.
@brianjohnhaas
Copy link
Contributor

brianjohnhaas commented Oct 26, 2017 via email

Use mostly SQLite column type affinities for clarity.

Use CHECK constraints to emulate unsigned integers, tinyint(1) that
had effectively functioned as booleans, and datetime columns.

Use WITHOUT ROWID optimization (https://sqlite.org/withoutrowid.html)
where it looks like it should work.

Use NUMERIC for most columns instead of FLOAT (REAL) to store values
precisely.
@nathanweeks
Copy link
Collaborator Author

OK, will do. Before advertising more broadly, I've done a second pass to the schema to implement a few optimizations (e.g., WITHOUT ROWID) and emulate additional data types with CHECK constraints where it seemed reasonable to do so. I didn't add foreign key constraints, but that might be a good idea for data integrity (e.g., catch software bugs).

@lgretton
Copy link

This is brilliant, I've hit the same obstacle on our HPC system due to the requirement for MySQL and was looking into doing this myself until I spotted your pull request. I see it hasn't been merged yet, is that likely to happen any time soon?

@brianjohnhaas
Copy link
Contributor

brianjohnhaas commented Jan 17, 2018 via email

@brianjohnhaas
Copy link
Contributor

brianjohnhaas commented Jan 17, 2018 via email

@nathanweeks
Copy link
Collaborator Author

Hi @brianjohnhaas , I think this would be more visible in the main repo, though (if you prefer) maybe initially in a feature branch. I'm certainly willing to watch the repo & submitting pull requests "from afar" in response to relevant issues/suggestions; however, if you'd rather consider adding me as a developer (with the understanding that my scope would be somewhat limited), that's fine with me as well.

@brianjohnhaas
Copy link
Contributor

brianjohnhaas commented Jan 17, 2018 via email

@nathanweeks
Copy link
Collaborator Author

Thanks, Brian---I'll try my best not to mess things up! ;)

@nathanweeks
Copy link
Collaborator Author

Closed in favor of #60

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants