boourns / scaffold Goto Github PK

It would be nice for the database to protect against NULL values in columns, and scaffold should make that the default.

@iamkevb

Opening an issue to track major issues with the current version of scaffold that could be solved either now or when generics land. Trying to focus on just the issues without solutioning. I'm also listing some issues that are actually dblib issues.

1. Being directly tied to SQLite will definitely limit it's popularity.

2. I run into an issue where migrations can only run once, and if the database is cleared, the migration will fail. The order of events is:

• Database already exists with table 'A' already created. One migration runs on startup, CreateTableA.
• I want to add a column 'foo' to table 'A'.
• I add column foo to the struct A and regenerate the scaffold a_sql. This updates the CreateTableA function to also create column foo.
• Since the first migration already ran, when I start the app and migrate the database nothing happens. SQL table still missing column foo.
• I add a second migration, AddFooToTableA that adds column foo to table A.
• I restart the application, column foo gets succesfully added since the second migration has never run.
• I delete my database (say, it was development)
• I restart the application. First migration runs, adding table A including column foo. Second migration runs, column foo already added, and the second migration fails.

3. Query interface is not type-safe and is not really discoverable. Remembering exactly what text to put into the conditions and joins is a bit tough. This is a pain but at the same time I'm worried the cure might be worse than the ailment.

4. Query interface does not support more complex concepts like grouping

5. Maybe scaffold should become a child directory of dblib since the two are intertwined, and possibly more intertwined as we go?

@iamkevb

what I'm currently thinking about how to use generics, let me know what you think

this is non-compilable pseudocode for now

// Model interface is provided by the scaffold library
type Model interface {
	// columns returns a map of SQL column names to pointers to the field
	Columns() map[string]interface{}
}

// input struct to scaffold, user writes this
type Person struct {
	ID int16
	Name string
}

// generated code defines the table and calls into the scaffold library
func (p *Person) Columns() map[string]interface{} {
	return map[string]interface{}{
		"ID": &p.ID,
		"Name": &p.Name,
	}
}

// this function is still nicer to use than the library
func SelectPerson(db dbutil.Queryable, conditions, vars) []Person {
   return scaffold.Select[Person](db, conditions, vars)
}

Along with Columns there could be a Schema generated that the scaffold library knows how to convert to, say, a CREATE TABLE statement, but I'm not sure how to do this without accepting that we're modelling the entire SQL language within Go (ala GORM).

The goals of the approach would maybe be:

• reduce footprint of generated code
• make it easier to implement Dialects / different database engines
• make it easier to register and extend with Hooks like AfterCreate, BeforeCommit, etc etc. This may not be worth the complexity but would be useful.

Downsides:

• definitely worried about suddenly having to model all of SQL in Go

All the following should work with scaffold:

	UpdatedAt time.Time `sqlType:"DATETIME" json:"updatedAt"`
	UpdatedAt time.Time `json:"updatedAt" sqlType:"DATETIME"`
	UpdatedAt time.Time `json:"updatedAt"`
	UpdatedAt time.Time