{"push_id":957079328,"size":1,"distinct_size":0,"ref":"refs/heads/master","head":"8a330299443354575e48fcbe8f386024e239fe51","before":"c784e47b21526f98b836088a373dc19396217701","commits":[{"sha":"8a330299443354575e48fcbe8f386024e239fe51","author":{"email":"d7e19930cc1f42c2d0781f4d9e6f1fe5891bf9cf@seantheprogrammer.com","name":"Sean Griffin"},"message":"Make `FromSql` and `FromSqlRow` more generic over the backend\n\nThis allows each backend to provide a \"value\" type that is used by\n`FromSql`. This is required for Sqlite support. While I can do some\nsemi-hacky nonsense to make Sqlite work with our current `ToSql`\nstructure, there's just no way I can make it work with our `FromSql`\nstructure.\n\nSqlite only returns c ints from its values, and there's no way I can\nknow at the row level the number of bytes that are needed for `FromSql`\nfor that specific sized integer.\n\nThis unfortunately means that we can no longer assume that all backends\nprovide `String: FromSql<VarChar, Self>`. We can bring this requirement\nback by changing `String: FromSql<VarChar, Pg>` to something like `Pg:\nCanDeserialize<VarChar, String>`. I'm unsure how this will interact with\ncoherence, and feels significanly less natural than the `NativeSqlType`\nchange that we made for this.\n\nI will likely make a similar change for `ToSql` in the future to make\nSqlite work in a less hacky manner.","distinct":false,"url":"https://api.github.com/repos/sgrif/diesel/commits/8a330299443354575e48fcbe8f386024e239fe51"}]}