faustinoaq changed the topic of #amber to: Welcome to Amber Framework community! | https://amberframework.org | Developer happiness, productivity and bare metal performance | GH: https://github.com/amberframework | Docs: https://docs.amberframework.org | Gitter: https://gitter.im/amberframework/amber | IRC Logger: https://irclog.whitequark.org/amber | Amber::Server.start
feepbot has quit [Ping timeout: 272 seconds]
feepbot has joined #amber
<FromGitter> <drujensen> ugh, that looks ugly
<FromGitter> <drujensen> `/root/ulayerpanel/lib/db/src/db/pool.cr:123: undefined reference to *Set(DB::Connection+)@Set(T)#delete<PG::Connection>:Set(DB::Connection+) ⏎ `
<FromGitter> <drujensen> undefined reference?
<FromGitter> <drujensen> did you update all your shards to the latest releases?
<FromGitter> <drujensen> probably should have added that to the release notes
<FromGitter> <drujensen> ```code paste, see link``` [https://gitter.im/amberframework/amber?at=5d4f8276c87a0963e74c9091]
<FromGitter> <drujensen> Also, any reason you are not pointing amber to `0.30.0` instead of a commit she?
<FromGitter> <drujensen> @nsuchy ^^^
_whitelogger has joined #amber
_whitelogger has joined #amber
_whitelogger has joined #amber
_whitelogger has joined #amber
_whitelogger has joined #amber
feepbot has quit [Ping timeout: 245 seconds]
feepbot has joined #amber
<FromGitter> <damianham> I am currently working on a Node.JS project implementing e-commerce payment facilities and they have an interesting technique to manage database schema. Rather than migrations they have a set of json files that describe the schema, one file per table or view. When the node server process starts up the database schema is checked against the json files and adjustments are made before the server starts for real. I
<FromGitter> ... thought it a bit weird at first but it is cool to be able to deploy and have the server self manage the db schema rather than having to run a migrations update should there be any changes. Also the number of files is static unless a table or view is added. I have worked on projects before with hundreds of migration ... [https://gitter.im/amberframework/amber?at=5d4ff8d59507182477bbeae6]
_whitelogger has joined #amber
<FromGitter> <drujensen> Hi @damianham I have attempted a similar approach with Granite. It would check the schema against the model defined fields and automatically migrate the tables
<FromGitter> <drujensen> The reason I abandoned it is that you can’t determine if a field is being renamed. You can drop and create a field but data migrations wouldn’t be possible. You cannot determine the intent of the changes. Especially if the database is several schemas old.
<FromGitter> <drujensen> I’m curious if they figured out how to solve that
<FromGitter> <drujensen> Also, there are cases where you may want to have constraints and indexes defined. We would need to include this in our models.
<FromGitter> <drujensen> finally, you may want to create a view which would be even more DSL.
<FromGitter> <drujensen> It seems to me, migrations is a better approach but I think it would be awesome if someone has figured all this stuff out
<FromGitter> <eliasjpr> @drujensen I’m willing for us to invest some time to remove dependencies from Amber
<FromGitter> <eliasjpr> I think the dependencies is right now is the worst experience of amber
<FromGitter> <drujensen> yeah. The @mosop dependencies are fairly deep and each of them is small. Very nodejs like. Also, he is not responding to PR requests.
<FromGitter> <drujensen> Amber includes the kitchen sink on purpose so I don’t think we want to eliminate features like i18n or templating capabilities. We could make it more modular though and only include at the project level.
<FromGitter> <eliasjpr> I agree with that
<FromGitter> <drujensen> 👍