TODO

[sgrif]

Note: All items should be implemented in a way that works on stable rust, unless otherwise specified. Compiler plugins are probably the most preferable for codegen, but we'll see what's possible.

• Insert
  • type safe API for inserting
  • returning new values
  • type signature verifying no constraints are violated
    • null in not null (e.g. not including a column in the query, when the column has no default)
    • foreign key violations (Within reason. Maybe newtype up serial columns)
• Update
  • type safe API for updating
  • returning new values
  • type signature verifying no constraints are violated
• Select
  • type safe API for simple usage
  • ^---- Revisit that once we flesh out where
  • Types that fully understand logical rules for aggregation
    • Disallow selecting a non-aggregate and aggregate without group by
    • Allow selecting multiple aggregates without group by
    • Disallow selecting non-aggregate with group by
    • Disallow selecting non-aggregate and aggregate with group by (presumably this is free)
    • Allow selecting grouped columns
    • Allow selecting grouped columns and aggregate functions with group by
  • unsafe API for arbitrary SQL
  • CODEGEN: type safe API for arbitrary SQL Not 0.1
• From
  • type safe API for single tables
  • type safe API for inner joins
  • type safe API for left joins
  • type safe API for right joins
  • ability to query more than two tables (should in theory be the same code for all join types)
  • type safe API for one to many associations
  • type safe API for optional one to one associations
  • type safe API for required one to one associations (must differentiate at the type level)
  • join clauses with complex ON
  • unsafe API for arbitrary SQL
  • CODEGEN: type safe API for arbitrary SQL (is this actually needed?) Not 0.1
• Where
  • type safe API for most usage (macros allowed, but still needs stable)
    • ensure all referenced columns are on a table being selected
    • equality
    • inequality
    • numeric comparison operators
    • string comparison operators (e.g. LIKE)
    • in I don't think we need to support IN statements, since we have = ANY
    • audit any other reasonably generic kinds to handle in a DSL
    • consider support for complex data type queries (array, json, etc)
      • Would be cool to do things like filter(json_col["foo"].eq("bar")), might be hard to support arbitrary data types.
    • IS NULL (does this need to be separate from equality?)
      • Yes, it should be, which also means we need special handling for optional RHS. I want to write thing.eq("foo"), not thing.eq(Some("foo")), which means the pattern for AR style equality will look like:

      • match value {
          Some(x) => thing.eq(x),
          None => thing.is_null(),
        }

  • unsafe API for arbitrary SQL
  • CODEGEN: type safe API for arbitrary SQL Not 0.1
• Having
  • type safe API allowing predicates with arbitrary aggregate expressions (0.2)
  • unsafe API for arbitrary SQL
  • Maybe? CODEGEN: type safe API for arbitrary SQL Not 0.1
• Limit, Offset, etc
  • type safe API
• Order
  • type safe API
  • unsafe API for arbitrary SQL
• Anything else we think we need for 0.1

[sgrif]

Issues in the language that need to be resolved or worked around:

• Overlapping impls of marker traits. Want to be able to define a generic impl of SelectableColumn for the various join sources, for any type that is a selectable column of either the left or right side. Invalid today since there would be overlap in the case that the left and right are the same, but this doesn't matter because there are no methods for ambiguity anway.
• Orphan impls of tuples. For Queriable to work with associations, we need to be able to implement it for a tuple with no types that we control. If we cannot resolve this in the language, it looks like it's possible to work around it by adding an unused type parameter that we can pass in w/ something we explicitly control.
  • This has not been resolved in the language, but as of 555993e I believe we have an acceptable workaround.

[sgrif]

I need to revisit this soon. Most things which are unchecked are going to be 0.2 or later, not 0.1. If anyone wants to help me out and make a new issue moving things over, I would ❤️ you forever

[sgrif]

Just glancing over this here's the status of unchecked items at the time of writing:

• determining that FK constraints are violated will be 0.2 or later (probably 0.2, I really like that idea).
• proper representation of aggregate rules is not possible in the language right now. It requires Tracking issue for allowing overlapping implementations for marker trait rust-lang/rust#29864 or specialization with lattice impls. This will be top of the priority list once it's possible, and is a blocker for 1.0 (if the language doesn't support this in time, the plan is to remove tracking of aggregate rules entirely)
• associations are 0.3, maybe not going to be a thing at all. I'm not sure there's value in actually having APIs in the ORM for this vs just saying the join you want, and than doing .group_by(|r| r.0) (group_by would have to come from iter_utils of course). I'm open to hearing use cases for supporting this in the library itself.
• JSON and other indexed query operators are unknown at this point, as I don't even know what support for those types should look like. The index operator will almost certainly require specialization, as I'll need to do something like impl<T> AsExpression<T> for Expression<SqlType=Anything>
• IS NULL I'll add tomorrow
• "CODEGEN: type safe api for arbitrary SQL" -- so in the past I had this idea where we can establish a database connection at compile time, stick the sql fragment behind SELECT * FROM table WHERE, which basically would let us type check it. But honestly, we have ended up with a really fucking expressive query builder. I don't think we need this. I'm open to feedback.