TODO about diesel HOT 3 CLOSED

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.

from diesel.

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

from diesel.

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 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.

from diesel.