Kevin Leung

In fact, I think we should support all basic Haxe data types and map them to the most sensible db type. But still allow using the specialized types in `Types`....

This may serve as a good starting reference: http://knexjs.org/

I quickly drafted some proposed syntax as follow. I am not sure if they are possible at all. Because I don't know if we can make the compiler properly type...

1. At first I just thought it is closer to the SQL syntax. But I agree that reversing could be better. `from(table).join(other).on(...).select(...).where(...)` `into(table).insert(...)` 2. I think this is mostly for...

I think the `UNLOCK TABLES` statement only unlock those locked by the current session. About the portability, could that be solved by separating each dialect into separate classes? ```haxe mysql.lockTable();...

Same for groupBy: `db.User.join(db.Post).on(User.id == Post.id).groupBy(f -> [f.User.id]);`

This is tricky. Easiest way is to let user specify the table name `@:foreign('table_name', id)`. Problem is that, we can't know table name from the table class itself.

> Currently there's no way to create a primary key on multiple columns. Well, you can put `@:primary` on several columns. But yes, the order is determined by the field...

As for the naming, we can exploit the call syntax like what we did in [tink_unittest](https://github.com/haxetink/tink_unittest/blob/6433cb878a0098403cd33d1e3b54289a3644c717/tests/RunTests.hx#L170): ```haxe @:index('index_name'(field1, field2)) ```

> Static extensions should work ;) I wonder what is the type of the generated table? Is it `tink.sql.Table`?