Conversation
| + Column renames in migrations [[https://github.com/Electron100/butane/issues/89]] | ||
| + prepared/reusable queries | ||
| + Improved custom support, including raw sql where clauses | ||
| + More precise spans in macro errors for invalid field names |
There was a problem hiding this comment.
These are likely a few easy improvements. Do we know some instances that need improvement?
| + prepared/reusable queries | ||
| + Improved custom support, including raw sql where clauses | ||
| + More precise spans in macro errors for invalid field names | ||
| + Remove timestamp from migration names |
There was a problem hiding this comment.
I quite like the timestamp being in the name, but it is problematic when git rebasing a change. I can write up an issue about this, but I probably wont be able to fully capture the original intent of this item.
| + Column renames in migrations | ||
| + Column renames in migrations [[https://github.com/Electron100/butane/issues/89]] | ||
| + prepared/reusable queries | ||
| + Improved custom support, including raw sql where clauses |
There was a problem hiding this comment.
"raw sql where clauses" is a reasonable clear enhancement. Im not sure what else falls under "Improved custom support"
| + Many backreferences | ||
| + Column renames in migrations | ||
| + Column renames in migrations [[https://github.com/Electron100/butane/issues/89]] | ||
| + prepared/reusable queries |
There was a problem hiding this comment.
IMO this isnt a limitation - there are some performance gains here, but ... I doubt typical users of butane would see this as a priority.
| ** vNext | ||
| + foreign key constraints in db, cascade setting | ||
| + foreign key constraints in db, cascade setting [[https://github.com/Electron100/butane/issues/21]] | ||
| + incremental save |
There was a problem hiding this comment.
This one isnt clear to me.
does this mean doing writes immediately when changing a struct instance? sounds crazy.
or Many.add writing immediately?
There was a problem hiding this comment.
The original intention of this line was save being able to do an update with only the fields that have actually changed, as a performance enhancement. However that really doesn't fit well with the current architecture of assigning directly to struct fields and I'm not sure I think it's a good idea any more. I think at this point I'd do something like DataResult (or like what Diesel does) to allow updates with a struct containing only a subset of the model fields.
| + foreign key constraints in db, cascade setting | ||
| + foreign key constraints in db, cascade setting [[https://github.com/Electron100/butane/issues/21]] | ||
| + incremental save | ||
| + Many backreferences |
There was a problem hiding this comment.
I guess this is simply a function to take the caller from a Many instance to the instance that "(owner table, key)" points to?
Seems so, and seems not too hard to do, and also quite useful.
2 participants
No description provided.