add support for type hints in :bindings and output-columns

[toolbar23]

I found that I couldn't use static_sqlite to handle some of my queries. The problem is that sometimes sqlite3 is not able to determine the type of an expression (input or output).

This adds support for type-hints, ie. when sqlite3 cannot derive the column type, then you can now alias the column (or adapt the name of the :binding) so that it contains a hint to the sqlite3-type.

Currently the format used is <name>__<INTEGER|REAL|TEXT|BLOB> or <name>__<INTEGER|REAL|TEXT|BLOB>__<NULLABLE|NOT_NULL>.

The upside is that the SQL-String is valid, so you can copy it over to/from another sqlite3 client. The downside is that __ might be used the client and that it is kind of ugly.

---

Update: Oh, I didn't notice that I added more stuff in this branch:

In addition to the fn's already created it now auto-creates two more:

• _first -> is a convenience function that returns an Option instead of a Vec for the case where you just want one item (similar to Java JPA's firstBy... methods. It wraps the normal query and checks if the Vec only has zero/one/more entries and returns Ok(None), Ok(Some(T)), Err().

• _stream -> returns an async Stream instead of a Vec, so that you can process large result sets without reading them all into memory.

It would be nice, if these two variants would be created on-request and not by-default, but I don't have a good idea how.

---

Open to any change-requests or ideas.

[swlkr]

I kind of want to keep it limited to valid sql only, even if it does sort of limit this lib

[toolbar23]

+1 - I also like to still be able to copy/paste the SQL from/to other tools. the proposed attributes would still be legal though.

I have no real idea about what a macro does/how exactly the tokenization etc works, but if the macro didn't just expect a string here

   let get_friendship = r#"
       select
           u1.name as friend1_name__TEXT,
           u2.name as friend2_name__TEXT
       from Friendship, User as u1, User as u2
       where Friendship.user_id = u1.id
             and Friendship.friend_id = u2.id
             and Friendship.id = :friendship_id
   "#;

but accepted additional "params" like

      let get_friendship = first(r#"
           SELECT
               u1.name as friend1_name,
               u2.name as friend2_name
           FROM Friendship, User as u1, User as u2
           WHERE Friendship.user_id = u1.id
                 AND Friendship.friend_id = u2.id
                 AND Friendship.id = :friendship_id
       "#,
       TypeHint::IsInteger("friendship_id"),
       TypeHint::IsText("friend2_name"),
       TypeHint::IsText("friend1_name"))

this would keep the SQL clearer.

[swlkr]

This is interesting, I actually had a feature in a previous version where you could infer a single row from limit 1 want to bring that back? instead of a _first suffix?

[toolbar23]

yes, I think that would be better than a suffix.

[swlkr]

This is actually pretty cool, never thought about streams, what if you made it more explicit, where you name the fn suffix with _stream then it's a stream?

[toolbar23]

good idea. i didn't like unneccessarily auto-creating fns anyway.

[toolbar23]

just changed this