Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Derive schema from table definition #264

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

ryskajakub
Copy link
Contributor

Hi sorry for a bit of inactivity, I adapted this PR to changes in master and added the typefunction that will replace TableColumn with Column for better inference. If this is OK, we can this typefunction - probably the generic version you talk about - to template haskell that is generated product-profunctors along with adapter and Default instance.

@xldenis
Copy link
Contributor

xldenis commented Jan 16, 2017

Will this allow things like generating insert statements / validating table schema on boot?
I'd love to be able to make sure that my database matches the expected (implicit) schema!

On a related note I've always wondered if it would be possible to model things like migrations as a type-level list, such that the resulting list can be reflected and checked for equality with the table definition / schema.

ie:

m1 = Migr [AddColumn "A"]
m2 = Migr [AddColumn "B"]

data T1 = T1 { a :: _, b :: _ } deriving ... -- table definition

migrate $ m1 `after` m2 -- somehow assert that result will have 2 columns a and b

@ryskajakub
Copy link
Contributor Author

Yes, It should allow it. During the table schema definition, user will specify all column info with required or optional. Then we can run many extractors, that will gather table info, be it for generating CREATE statements, querying and also checking that the schema in database is equivalent to the declared and in case it's not it can suggest some ALTERs .

@xldenis
Copy link
Contributor

xldenis commented Jan 16, 2017

in case it's not it can suggest some ALTERs .

I don't think this a good idea but it's not relevant right now anyways.

@tomjaguarpaw
Copy link
Owner

Thanks for this @ryskajakub! Can you rebase on master so that the tests pass?

@ryskajakub
Copy link
Contributor Author

I fixed all errors but the one which uses Table's Functor. Why is this needed? It looks like this can be substituted by running the queryTable and then applying the operations. Apart, perhaps, the case when you want to "hide" some columns from querying from the table.

If that would be needed, the Column type would be needed to be inserted to the TableProperties during the Table declaration, not during the querying. Also, there would need to be added extra type to the TableProperties.

Or it could be designed differently.

@tomjaguarpaw
Copy link
Owner

Having looked at this again I think that the changes are too invasive. I don't like the idea of adding TableColumn. It's one of those things that complicates type inference. Yes, we already have several such things but I don't want any more if we can avoid it!

Instead I suggest that we add another field to TableProperties:

data TableProperties writerColumns viewColumns = TableProperties
   { tablePropertiesWriter :: Writer writerColumns viewColumns
   , tablePropertiesView   :: View viewColumns
   , tableColumns          :: [(ColumnName, ColumnType)]
 }

type ColumnName = String
type ColumnType = String

The we will have to restrict required and optional a little bit:

required :: String -> TableProperties (Column a) (Column a)
required columnName = T.TableProperties
  (T.required columnName)
  (View (Column (HPQ.BaseTableAttrExpr columnName)))
  [(columnName, showPGType (Proxy :: Proxy a))]

optional :: String -> TableProperties (Maybe (Column a)) (Column a)
optional columnName = T.TableProperties
  (T.optional columnName)
  (View (Column (HPQ.BaseTableAttrExpr columnName)))
  [(columnName, showPGType (Proxy :: Proxy a))]

Then I'm pretty sure we can get all or most of the table creation info we need out of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants