paupino / psqlpack Goto Github PK

Probably slog.

Requirements:

• Send errors to stderr

Validate that we know about custom types before we use them.

Relies on #19 which generates the order.
Once the order has been generated we should be able to use this to help generate changeset instruction ordering. Some things are implied. e.g. Database is always first, Schema is always second. However somethings are not, e.g. table ordering.

Another item which may need investigation is function ordering. These should come after table generation however they itself need ordering. At the moment we ignore this ordering due to lack of function parsing.

Currently, the system requires a packaged "psqlpack" in order to publish whereby this should not necessarily be required.

We probably need to document these a little bit via a readme first up. Ideally I'd also take the time to document project.json also.

I think these should be relatively simple as they aren't dependent.

This includes:

• New columns
• Column modification
• Dropped columns

At the moment, functions aren't parsed therefore don't contribute to topological ordering. This is required in order to avoid dependent function bugs.

Currently, the complex solution generation is putting reference tables after some other dependent tables. This may be due to an equivalent weight being generated therefore we may need some additional logic surrounding this to cater for this scenario.

Implement error recovery into LALRPOP. This is not so that we can recover from the error but moreso handle it a little better. For example, it'd be nice having the span results so we could potentially underline the error in the CLI.

This will allow us to set up a formal "testing" period whilst giving people the ability to keep up to date.

May need to order them - how can we determine this?

Currently primary key and foreign key constraints will issue a drop/create due to not all versions of Postgres supporting the ALTER statement. After #89 is completed, we should look at supporting these statements as they are likely more efficient.

At the moment, it will only work on unix however it'd be nice if it were multi-platform.

Also, plug build status into README.md.

Add in some further options:

• allow_drop_tables
• allow_drop_columns
• allow_drop_primary_constraints
• allow_drop_foreign_constraints

Perhaps we should also consider expanding the allow_unsafe_operations so that it is more explicit.

I think we're going to have to really think about how to implement these properly. They can create their own types/schemas/tables/functions etc which is useful information for post compilation steps. e.g. we may want to error when we find a dependency that is unrecognized, however at the moment things like ST_POINT which come as part of postgis aren't able to be accurately captured.

Perhaps we create explicit psqlpack packages which can be linked? If we do that, how do we maintain them? Who maintains them?

At the moment, it'll modify all the time however it'd be nice if there was better change detection both at a parameter/return type level and also at the body level.

Output lexer tokens (Accept, State, Replace) when logging is set to verbose.

e.g. TablesOnly, FunctionsOnly, TypesOnly etc.

Define the minimum PG version that we support and then expand Travis tests to provide coverage of these as much as possible. Current tests use 9.4.

Add to publish profile to turn on/off this option (i.e. versus adding to the end).

Command variables will allow in place variable matching to be applied to scripts on parse. This could be resolved entirely at the Lexer level. In saying that, we may want to have some better lexer Debug level logging before doing this i.e. start logging symbols, state change as well as symbol replacements (this task).

We should be able to search . by default (like cargo)

Create an --init command to help create a new psqlpack project.

I'm thinking MIT - what are others thoughts?

These may also need to be ordered however I think we can do that within the project.json file.

From this we can then use it to do the Change Diff etc as opposed to raw SQL statements against each object.

Validate that the indexes reference tables/columns it knows about.

At the moment I send them to stdout. It'd be good to redirect them to stderr.

That way we can eventually consume the library for tooling.

• framework/
• cli/

This could be output within the report possibly however it'd be useful to show for debugging. Technically it should be called when loading the dacpac also (i.e. load_project).

Use CREATE OR REPLACE - for modification detection we should use checksum of the body literal for now.

Does it need one? Perhaps I just open source this?

The project file is pretty dumb at the moment however could benefit from include/exclude filters with pattern matching.

Currently indexes are implicitly ignored. Supporting indexes is important for psqlpack being used upon production databases.

This includes:

• New constraints
• Modified constraints (TODO: which pg schema to check? pg_catalog?)
• Dropped constraints

Let's implement a release step through Travis which pre-packages binaries for common OS combinations.

To avoid writing a grammar parse function bodies within the lexer.

The README is a little out of date now and is need for an update.

Currently we have unit tests covering some delta changes however what would be super useful is also including integration tests for travis to run.

This will also allow us to accurately understand coverage from an integration perspective.

Currently table constraints are ignored when loading via Package::from_connection. These needed to be added so that add/add conflicts stop happening.

Ordering may be important if the type is an alias.

This should be the first step in the process.

Loading project references...
Loading project files...
Building the project model and resolving object interdependencies...
Validating the project model...

We should define contribution guidelines up front. Similar to this

At the moment it dumps what it plans to do. It'd be nice if it gave advice e.g. data movement.

This is so that these will be more of an assertion as opposed to a modify etc.