Make selecting all columns independent of schema order

[trueqbit]

I have the following problem: sqlite_orm serializes the expressions select(object<T>(), ...) and select(asterisk<T>(), ...) as select * from T. If the underlying schema as stored by SQLite does not match the schema defined in the code via make_table(), then the order of the columns in the result set will be different. Best left to your imagination, either filling an object or accessing the values of the result tuple produces garbage.

For me, this happens because I create and update the schema outside of sqlite_orm. As a good programmer, I insert columns in the schema definition in logically correct places, but adding a column during a schema update obviously adds it to the end of the table. I have not investigated sqlite_orm's schema migration, but I imagine it would exhibit the same problem.

So my suggestion is to write out the column names in the select, which is a good practice anyway. And since I depend on it, I would implement it in a fork, however it's preferrable to have it in sqlite_orm itself.

[fnc12]

yes it is a know issue. The case is what you are saying is right - it will eliminate some concerns that some users can face. But also sqlite_orm is designed to be able to call all possible queries including SELECT *. If we change * to column list we'll remove an opportunity to call SELECT *. That's not good cause sometimes users know what they want to call for sure

[trueqbit]

Sure, it's called "asterisk" for a reason :) The bad thing is that the problem hits you unexpectedly and is a silent type hole. It's not even obvious to experts at first glance, so imagine users who just want to make things work or just didn't think of this problem spot.

Writing out the columns yourself is tedious, plus error prone and doesn't look pretty.

So how about a flag that can be passed to object() and asterisk()? To keep the surprise and support overhead to a minimum, I would make writing out column names the default and leave the asterisk to "power" users. But if you think this is too unexpected, we can also flip the responsibility for creating a correct SQL statement.

[fnc12]

Good idea. How do you see this API?