cartodb-postgresql/CONTRIBUTING.md

65 lines
2.2 KiB
Markdown
Raw Permalink Normal View History

2014-06-17 16:38:18 +08:00
The development tracker for cartodb-postgresql is on github:
http://github.com/cartodb/cartodb-postgresql/
Bug fixes are best reported as pull requests over there.
Features are best discussed on the mailing list:
https://groups.google.com/d/forum/cartodb
Adding features to the extension
--------------------------------
Extension features are coded in scripts found under the
"scripts-available" directory. A feature can be a single function
or a group of function with a specific scope.
The "scripts-enabled" directory contains symlinks to the scripts
in "scripts-available". Any symlink in that directory is automatically
included in the extension. Numbering can be used to enforce the order
in which those scripts are loaded.
Scripts would be best coded in a way to be usable both for creation
and upgrade of the objects. This means using CREATE OR REPLACE for
2014-08-22 01:05:04 +08:00
the functions, and whatever it takes to check existence of any previous
2014-06-17 16:38:18 +08:00
version of objects in other cases.
When used as an extension (probably always from version 0.2.0 onwards)
all the objects will be installed in a "cartodb" schema. Take this into
account to fully-qualify internal calls to avoid (possibly dangerous)
name clashes.
2014-08-22 01:05:04 +08:00
Every new feature (as well as bugfixes) should come with a test case,
see next section.
2014-06-17 16:38:18 +08:00
Writing testcases
-----------------
Tests reside in the test/ directory.
You can find information about how to write tests in test/README
Testing changes live
--------------------
Testing changes made during development requires upgrading
the extension into your test database.
During development the cartodb extension version doesn't change with
every commit, so testing latest change requires cheating with PostgreSQL
2015-10-06 17:33:56 +08:00
as to enforce the scripts to reload. To help with cheating, "make install"
also installs migration scripts to go from "V" to "V"next and from "V"next
to "V". Example to upgrade a 0.2.0dev version:
```sql
2015-08-18 20:56:23 +08:00
ALTER EXTENSION cartodb UPDATE TO '0.2.0next';
ALTER EXTENSION cartodb UPDATE TO '0.2.0dev';
```
Starting with 0.2.0, the in-place reload can be done with an ad-hoc function:
```sql
SELECT cartodb.cdb_extension_reload();
```
2015-08-18 20:56:23 +08:00
A useful query:
```sql
2015-08-18 21:08:35 +08:00
SELECT * FROM pg_extension_update_paths('cartodb') WHERE path IS NOT NULL AND source = cdb_version();
2015-08-18 20:56:23 +08:00
```