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
<FromGitter> <Blacksmoke16> @robacarp did you ever notice that in Granite `typeof(@name)` is diff than `typeof(self.name)`
<FromGitter> <Blacksmoke16> in that the former would be type `String | Nil` while latter would be type `String`
<FromGitter> <robacarp> Nope
<FromGitter> <Blacksmoke16> prob because the `field!` macro is a method, all properties by default are union of type | Nil
<FromGitter> <Blacksmoke16> also ill have a pr prob sometime in next week for virtual properties as im calling them...that exist in model but dont get saved to db
<FromGitter> <robacarp> I’ve done that myself several time s
<FromGitter> <basilthesecond_gitlab> btw guys, I saw an issue related to more documentation. Are you guys planning to generate docs with `crystal doc`?
<FromGitter> <basilthesecond_gitlab> or is there some other tool yall are gonna use?
<FromGitter> <Blacksmoke16> in relation to Granite or Amber?
<FromGitter> <basilthesecond_gitlab> amber
<FromGitter> <basilthesecond_gitlab> well, if you have info about granite then I would appreciate that as well
<FromGitter> <Blacksmoke16> for Granite you can generate the docs yourself, they aren't in the repo
<FromGitter> <Blacksmoke16> but we do have file in the `docs/` directory in the repo with info on various topics
<FromGitter> <basilthesecond_gitlab> btw wha'ts the proper way to generate migrations when I update my model?
<FromGitter> <basilthesecond_gitlab> `amber g migration` seems to only generate a blank micrate file
<FromGitter> <Blacksmoke16> yea, which you define the SQL for the migration
<FromGitter> <basilthesecond_gitlab> ah ok, so you don't have autogenerated migrations like when you scaffold?
<FromGitter> <Blacksmoke16> mm to be far i never actually used amber so im not too familiar with that side of things
<FromGitter> <Blacksmoke16> im pretty sure it wraps micrate, which you have to define the raw SQL for each change tho
<FromGitter> <basilthesecond_gitlab> well, there's an opportunity for something! :)
<FromGitter> <basilthesecond_gitlab> can someone from the amber project say if that's something that might be useful? An updater that will create a migration once a model is changed?
<FromGitter> <robacarp> @basilthesecond_gitlab I think it would be useful, but the whole migration system needs an overhaul. Micrate is basically abandoned, and requiring hand written sql for migrations kind of defeats the purpose of having an ORM abstract away the database.
<FromGitter> <robacarp> I’m using a rather nice fork of micrate thats essentially been completely rewritten from vlaudfast on GitHub, but it’s still far too manual for Granite. My personal opinion is that Granite should provide a migration DSL, but getting that to work is going to be fiddly because the code shouldn’t be loaded at compile time.
<FromGitter> <robacarp> I’ve thought about using a parser library and writing a runtime language, or implementing HCL or something, but that’s just such a huge lift.
<FromGitter> <basilthesecond_gitlab> might it be possible to integrate with the watch procedure?
<FromGitter> <basilthesecond_gitlab> I think that would make the most sense: don't do anything unless a file is updated and then stop everything and swap the appropriate tables
<FromGitter> <robacarp> I wouldn’t want anything to automatically run migrations in dev or release
<FromGitter> <yorci> @faustinoaq are you okay man? i dont see you anymore here
hightower6 has joined #amber
hightower5 has quit [Ping timeout: 260 seconds]