Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Order of columns matter in eager loading, it causes problems sometimes #809
Comments
|
Hi @vladvelici. I think this is a fine change to go ahead and implement. In reality I think that if we were to go back to this, bind should start failing if it finds column results for which it has no place to bind to again. I don't believe it's a very complicated change. |
…tionships As stated in volatiletech#809, the order of columns may cause errors during eager loading. This commits only replaces `select *` in m2m relationships eager loading with actual column names, since this is the only place eager loaded data is scanned manually with generated code. Change-Id: I6fe775ed672a1ef303385b362898402f468108fe
…tionships As stated in volatiletech#809, the order of columns may cause errors during eager loading. This commits only replaces `select *` in m2m relationships eager loading with actual column names, since this is the only place eager loaded data is scanned manually with generated code. Change-Id: I173761a2b4ab0777cbe093bd50a81c561cef506a
…tionships As stated in volatiletech#809, the order of columns may cause errors during eager loading. This commits only replaces `select *` in m2m relationships eager loading with actual column names, since this is the only place eager loaded data is scanned manually with generated code.
…tionships As stated in volatiletech#809, the order of columns may cause errors during eager loading. This commits only replaces `select *` in m2m relationships eager loading with actual column names, since this is the only place eager loaded data is scanned manually with generated code.
…tionships As stated in volatiletech#809, the order of columns may cause errors during eager loading. This commits only replaces `select *` in m2m relationships eager loading with actual column names, since this is the only place eager loaded data is scanned manually with generated code.
…tionships As stated in volatiletech#809, the order of columns may cause errors during eager loading. This commits only replaces `select *` in m2m relationships eager loading with actual column names, since this is the only place eager loaded data is scanned manually with generated code.
Hello.
This is somewhat related to #587 but it's not about selecting custom columns. It's about making the order of the columns in the database irrelevant for the queries by getting rid of
select *.Use case: It's not important most of time time, but we encounter this problem in our development when we use migrations. With postgres you can't specify the position of columns. If an up migration removes a column and a down migration re-adds it, the order of the columns is not preserved after a migrate up followed by migrate down operation (which happens often in development and reviewing pull requests).
A fix would be to generate queries that specifically select columns by name as opposed to
select *in eager loading methods - this way even if the columns in the database are different and models weren't regenerated, the application won't crash. Is this a complicated change? Would this be fixed anyway by the implementation of #587?Using sqlboiler v4.2.0 with postgres 9.6 if it's relevant.