Juraj Kirchheim

@deathbeam Yes, I can see how the documentation might be misleading. I will reopen this issue and close when I've had time to improve it. The short version: tink uses...

I had no idea. Good to know ^^ > In fact, I think we should support all basic Haxe data types and map them to the most sensible db type....

Two questions: 1. It would be possible to do it that way around (`select` before `from`). What are the benefits? If we do it the other way round (as it...

Well, the `UNLOCK TABLES` looks a bit frightening to be honest, as it seems that it could inadvertently unlock other tables, but then again my SQL knowledge is equally limited...

I suspect the row type for the result set does not have final fields, mostly because https://github.com/haxetink/tink_macro/issues/17

Sounds good. An interesting question is how exactly the table should be identified (ideally it would be the name of the field on the database object that holds the table).

You can put meta on typedefs, but it's a bit tricky to pick it up (you have to follow the type one by one).

Ok, ignore that. Turns out I have dealt with this before: https://github.com/haxetink/tink_macro/blob/master/src/tink/macro/Types.hx#L52 :D

Static extensions should work ;) But yeah, let's see what we can do.

I should add that the `WHERE` and `ON` should ideally also be able to do `db.User.WHERE(name == "JohnDoe")` and even `db.User.join(db.Post).ON(User.id == author)` (where `author is resolved as `Post.author` as...