<FromGitter>
<drujensen> I think I am still leaning toward @robacarp idea inside a `do end` block. For some reason the annotations just doesn’t read well. Ruby reads like a text book if its done right.
<robacarp>
I worry that the annotations feature of crystal feels underdeveloped too, like mutable constants
<FromGitter>
<drujensen> yeah, true
<FromGitter>
<drujensen> bleeding edge stuff. but heck, I’ve rewritten granite 10 times by now. lol.
<FromGitter>
<drujensen> ;-)
<FromGitter>
<drujensen> feels like we are going full circle
<FromGitter>
<Blacksmoke16> hehe
<FromGitter>
<Blacksmoke16> long as each version is better than the last
<FromGitter>
<drujensen> I kinda like the `sql_mapping`
<FromGitter>
<Blacksmoke16> i could go for @robacarp 's example.
<FromGitter>
<Blacksmoke16> however my gripe with the mapping style of things is it requires more inherit knowledge of the ORM to use. Versus `oh i just declare properties like i always do in my classes, inherit from Granite::Base, and add some annotations and im done`
<FromGitter>
<drujensen> does it?
<FromGitter>
<drujensen> seems like the annotations would require the same knowledge, no?
<FromGitter>
<Blacksmoke16> not that we have any way of testing it atm, but what happens if you do a sql mapping and also provide properties? do the properties exist on the model but not in db?
<FromGitter>
<drujensen> yeah, they will fail because the macro would try to create the same property
<FromGitter>
<Blacksmoke16> er i mean like if they have separate names
<FromGitter>
<drujensen> but it would be the same as now declaring the `property` and then `field`
<FromGitter>
<drujensen> oh
<FromGitter>
<Blacksmoke16> like virtual properties
<FromGitter>
<drujensen> that should be fine
<FromGitter>
<drujensen> the mapping would only persist the fields defined
<FromGitter>
<Blacksmoke16> fair enough
<FromGitter>
<drujensen> JSON would be interesting though
<FromGitter>
<drujensen> back to annotations?
<FromGitter>
<drujensen> for json?
<FromGitter>
<Blacksmoke16> if the mapping creates properties under the hood it should just work
<FromGitter>
<Blacksmoke16> i guess my way of thinking about this is like a model class should look very similar to a normal crystal class
<FromGitter>
<drujensen> yeah, i agree. The `finished` macro made that possible.
<FromGitter>
<drujensen> and mutable constants
<FromGitter>
<Blacksmoke16> like json/yaml use annotations, my third part shard does, if things continue down this road having the properties themselves exposed makes supporting stuff like that much easier
<FromGitter>
<drujensen> yeah, i agree
<FromGitter>
<Blacksmoke16> with a lot less logic under the hood to manage all of that
<FromGitter>
<drujensen> if this is the way crystal is going...
<FromGitter>
<drujensen> but i will become less a fan of it…:-(
<FromGitter>
<Blacksmoke16> :shrug: just have to see how it goes and go from there
<FromGitter>
<drujensen> yeah, i think its great you are investigating this
<FromGitter>
<drujensen> if crystal adopts it in the core, i think we should as well
<FromGitter>
<drujensen> its still 10 times nicer than Go.
<FromGitter>
<Blacksmoke16> coming from PHP land, we use Symfony at work
<FromGitter>
<drujensen> or PHP
<FromGitter>
<Blacksmoke16> we take good advantage of their annotations and it makes things super slick imo
<FromGitter>
<anamba> btw, to add to the granite discussion, i have been working on an ORM for Neo4j: https://github.com/upspring/neo4j_model.cr i am still new to crystal, so keep that in mind (~5-6 weeks experience now), but i went with using regular Crystal properties. Planning to try out annotations for special cases, but right now I don't use them.
<FromGitter>
<Blacksmoke16> its pretty much same implementation as you are doing now as far as i can tell, just using annotation to specify which properties should be persisted
<FromGitter>
<Blacksmoke16> but could also work other way, persist all properties unless they are annotated with like `@[Granite::Virtual]`
<FromGitter>
<Blacksmoke16> or something
<FromGitter>
<robacarp> I agree that Granite should follow Crystal core direction... if they really embrace annotations, then it makes sense for Granite to follow suite. Admittedly I’m not as up on crystal style in the compiler as I used to be, but in 0.26 the only code in stdlib that used it was the json/yaml stuff. It makes me nervous that we would be swapping one deprecated paradigm (mutable constants) for another. ⏎ ⏎ Admittedly
<FromGitter>
... nerves aren’t facts, but any changes in this area of Granite are big, breaking, and highly visible... so I’d hope not to be making drastic changes tooo often.
<FromGitter>
<Blacksmoke16> for sure, not planning on it getting merged anytime soon, more of just exploring possibilities/limitations atm
<FromGitter>
<Blacksmoke16> at least then we'd be more prepared/informed to make a decision
<FromGitter>
<robacarp> Absolutely! I’m a huge fan of exploratory coding
<FromGitter>
<robacarp> One thing I *love* about annotations is how they stack vertically rather than just extend the line
<FromGitter>
<Blacksmoke16> indeed
<FromGitter>
<robacarp> Another is how widely extensible they are — third party libraries can be easily added which can read them when included into a model
<FromGitter>
<Blacksmoke16> for sure, so could allow for granite extensions that can be installed separately for example
<FromGitter>
<Blacksmoke16> was thinking of doing something like that for my validation shard, would be quite slick
<FromGitter>
<Blacksmoke16> not sure on what or how tho, idea was granite could implement an abstract class that can be implemented by third part extensions
<FromGitter>
<Blacksmoke16> oh btw, was working on the aggregate functions, how could i better integrate them with the query builder? as of now i dont think it works like `Model.where(:value, :gt, 100).min(:value, Int32)`
<FromGitter>
<Blacksmoke16> like it would have to be able to edit the `select` portion of the query that gets executed on `select`
<FromGitter>
<Blacksmoke16> vs just running its own query
<FromGitter>
<naiyt> Well of course I figure it out as soon as I ask for help XD. Changing the resource to `resources "/entries", Api::V1::EntryController, only: [:index]` seems to fix it, guess you need that leading slash
<FromGitter>
<drujensen> shouldn’t need it. looks like a bug to me
<FromGitter>
<drujensen> glad you figured it out
<FromGitter>
<naiyt> Yeah, might be a bug...doesn't seem to work without the leading slash, which is a bit odd because `amber routes` reports the route correctly. After double checking the docs I noticed there was a leading slash in the examples
<FromGitter>
<elorest> No the leading `/slash` requirement is intentional. @drujensen. @naiyt glad you figured it out.
<FromGitter>
<elorest> Maybe we could/should change it?
<FromGitter>
<naiyt> Not sure if it matters, but there's not a requirement for a leading slash for a Rails resource, which I think is what confused me at first. If you wanted to keep it as a requirement maybe it would be good to have a runtime error when the routes are first evaluated, if you forgot it?