I have the need for migrations in PrairieSchedule. I'd like to revisit the idea of modularizing the database initialization parts of PrairieLearn into PrairieLib.

I was thinking some way to pass in the project name and path into the migrations.init() function. The migrations table would need to be updated with a unique index and project so each one has its own numbers.

The sprocs stuff could use some updating too, like getting its file list from the directory (like migrations does). Maybe rename it to something like initializations since those are run each time the server runs.

Both functions could be pulled into the same library?

I'm just brainstorming before actually changing anything. Worth the effort?

Change sql-loader.load() to return an object rather than a string, including a unique name:

{
    name: filename + ‘-‘ + block_name,
    text: sql_string
}

See https://node-postgres.com/api/client#-code-client-query-config-queryconfig-gt-promise-lt-result-gt-code-

This triggers execution plan caching in the DB: https://node-postgres.com/features/queries#parameterized-query

Preferably controlled via environment variable. It would make development a lot easier if we didn't have to restart the server after every sql change.

If passed params as an object, call() should use the named-argument syntax: https://www.postgresql.org/docs/10/static/sql-syntax-calling-funcs.html

The SQL will look like:

SELECT * FROM func(param1 => $1, param2 => $2)

From PrairieLearn/PrairieLearn#927

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

The locking race condition we're facing on PL right now logs the following after a client idles for 10 minutes:

Oct 24 22:28:19 ip-10-0-0-204 node: throw er; // Unhandled 'error' event
Oct 24 22:28:19 ip-10-0-0-204 node: ^
Oct 24 22:28:19 ip-10-0-0-204 node: error: terminating connection due to idle-in-transaction timeout
Oct 24 22:28:19 ip-10-0-0-204 node: at Connection.parseE (/PrairieLearn/node_modules/@prairielearn/prairielib/node_modules/pg/lib/connection.js:604:11)
Oct 24 22:28:19 ip-10-0-0-204 node: at Connection.parseMessage (/PrairieLearn/node_modules/@prairielearn/prairielib/node_modules/pg/lib/connection.js:401:19)
Oct 24 22:28:19 ip-10-0-0-204 node: at Socket.<anonymous> (/PrairieLearn/node_modules/@prairielearn/prairielib/node_modules/pg/lib/connection.js:121:22)
Oct 24 22:28:19 ip-10-0-0-204 node: at Socket.emit (events.js:203:13)
Oct 24 22:28:19 ip-10-0-0-204 node: at Socket.EventEmitter.emit (domain.js:471:20)
Oct 24 22:28:19 ip-10-0-0-204 node: at addChunk (_stream_readable.js:294:12)
Oct 24 22:28:19 ip-10-0-0-204 node: at readableAddChunk (_stream_readable.js:275:11)
Oct 24 22:28:19 ip-10-0-0-204 node: at Socket.Readable.push (_stream_readable.js:210:10)
Oct 24 22:28:19 ip-10-0-0-204 node: at TCP.onStreamRead (internal/stream_base_commons.js:166:17)
Oct 24 22:28:19 ip-10-0-0-204 node: Emitted 'error' event at:
Oct 24 22:28:19 ip-10-0-0-204 node: at connectedErrorHandler (/PrairieLearn/node_modules/@prairielearn/prairielib/node_modules/pg/lib/client.js:199:10)
Oct 24 22:28:19 ip-10-0-0-204 node: at Connection.connectedErrorMessageHandler (/PrairieLearn/node_modules/@prairielearn/prairielib/node_modules/pg/lib/client.js:206:7)
Oct 24 22:28:19 ip-10-0-0-204 node: at Connection.emit (events.js:203:13)
Oct 24 22:28:19 ip-10-0-0-204 node: at Connection.EventEmitter.emit (domain.js:471:20)
Oct 24 22:28:19 ip-10-0-0-204 node: at Socket.<anonymous> (/PrairieLearn/node_modules/@prairielearn/prairielib/node_modules/pg/lib/connection.js:126:12)
Oct 24 22:28:19 ip-10-0-0-204 node: at Socket.emit (events.js:203:13)
Oct 24 22:28:19 ip-10-0-0-204 node: [... lines matching original stack trace ...]

It's been bugging me to track down why we're getting an uncaught error event (and subsequently crashing) when we are passing an error handling function to

My running theory is we also need to hook into the client.on('error') a little further down in that function

with something like

client.on('error', idleErrorHandler);

I don't have a great way of testing that, but I would like to get to the bottom of this, so I figured I'd start a discussion/PR here.

• logger.js
• csrf.js

Dave also has some shared library code between PS and PL in plps-utilities that should get ported over too.

I was just poking around the PrairieLearn codebase and realised that this is over there now.

Should this repository be marked as deprecated now to avoid confusion?