mdmoss / doobie-codegen Goto Github PK

Instead of

ALTER TABLE x ADD a TEXT; ALTER TABLE x ADD b TEXT; ALTER TABLE x ADD c TEXT;

it should be possible to do this

ALTER TABLE x ADD a TEXT, ADD b TEXT, ADD c TEXT;

without gen complaining.

Currently, the semantics of multiget (by primary key) provide that the output will be ordered the same as the input, and duplicate keys in the input will correspond to duplicate rows in the output. These semantics can be used for zipping the output with a list containing the input, although often it is unnecessary for this condition to hold.

The semantics of multigetBy are similar, although for each input there might be multiple rows of output, and the relative ordering of rows with the same key is undefined. I am not convinced these semantics are particularly useful, so I am inclined not to preserve them in a future version.

In either case, it may be helpful optimisation to provide a "fast" multiget which provides different or lesser guarantees. For example, output order could be undefined, or sorted by key (which would not pressure the database significantly more than leaving output order undefined). Additionally, a version of multigetBy could sort by foreign key then primary key so that there is a well-defined total ordering.

Including CURRENT_TIMESTAMP.
I will probably deal with this.

I will deal with this.

Would be nice if it had;

"ALTER TABLE " ~ TableRef ~ "ALTER COLUMN " ~ ValidIdentifier ~ "SET " ~ ColumnProperty ~ ";"

Currently, they just use id.

• Row fragment spacing
• Splitting multiget queries

At some stage we merged all the multiget queries into one. This was done to improve compile times.

Later, we discovered the reason why this makes compilation faster: The scala compiler needs to build up an implicit Meta for getting data out of JDBC and into a Row case class. We now generate Meta instances for Row so the compiler doesn't need to do extra work to generate one.

Now that we are doing this, compiling multiple multiget queries should be fast again. Having separate queries will make it easier to interpret DB logs and performance statistics, which is quite valuable for debugging and profiling.

This is possible with upserts, apparently.

Will deal with this.

This would make copying things much neater.

This could be done with Default \/ T or Option[T].

This reflects the standard behaviour of most databases (and probably the standard).

A way to include a column in creates, but exclude them from updates.

It would be useful to have queries generated for look-ups by unique fields.

Generate wrappers for multi get by fields to take in a singular field, as opposed to list

For example, allUnbounded and all can share the same query underneath.

ALTER TABLE article owner TO someuser;

Getting error
Invalid input 'o', expected [ \n\t], 'A' or 'D' (line 1, column 37):

COMMENT ON COLUMN artilce.id IS 'It is an auto increamented id';

Invalid input 'E', expected 'i' (line 1, column 5):

I'll deal with this

A comment on the first line seems to be needed to trigger this

Example file:

-- A comment
-- doobie-codegen: off
DROP TABLE tbl;
-- doobie-codegen: on

Unexpected end of input, expected AlterSequence, With, Update, Commit, CreateTable, Begin, CreateExtension, DropView, Delete, DropTable, CreateView, CreateSchema, Insert, CreateIndex or AlterTable (line 1, column 1):

^
[error] (run-main-4) ParseError(Position(0,1,1), Position(0,1,1), <21 traces>)
ParseError(Position(0,1,1), Position(0,1,1), <21 traces>)
        at org.parboiled2.Parser.done$1(Parser.scala:185)
        at org.parboiled2.Parser.phase4_collectRuleTraces$1(Parser.scala:196)
        at org.parboiled2.Parser.__run(Parser.scala:209)
        at mdmoss.doobiegen.Runner$$anonfun$run$1.apply(Runner.scala:76)
        at mdmoss.doobiegen.Runner$$anonfun$run$1.apply(Runner.scala:75)
        at scala.collection.immutable.List.foreach(List.scala:381)
        at mdmoss.doobiegen.Runner$.run(Runner.scala:75)