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
_whitelogger has joined #amber
<FromGitter> <drujensen> @Blacksmoke16 @robacarp I merged in the latest PR’s for granite and i’m looking to migrate the `querying` to the new Query Buildeer, however I am kinda stuck since they are quite different approaches.
<FromGitter> <drujensen> @robacarp I know its been a while since you started working on this so not sure but am interested if you had a vision for how this was going to work
<FromGitter> <drujensen> I would like to make the Query Builder a first class citizen and extend the base class out of the box
<FromGitter> <drujensen> but there is conflicts with `first` and `count`
<FromGitter> <drujensen> let me know how we can do this since it probably the number 1 requested feature
<FromGitter> <Blacksmoke16> im not too familiar with the query builder thing unfortunately
<FromGitter> <Blacksmoke16> but ill take a look tomorrow
<FromGitter> <drujensen> ok. thanks. I am playing around right now to see if I can at least get it extended
<FromGitter> <drujensen> without breaking to much
<FromGitter> <robacarp> So...the difference should be moot, right? Before including the query builder, #first runs a query and returns a single record. After it should do the same thing. Same with count.
<FromGitter> <robacarp> It’s valuable to keep a raw query syntax available easily, but writing sql on a regular basis is asking for trouble — it’s way too easy to shoot yourself in the foot and introduce injection vulnerabilities and other bugs
<FromGitter> <drujensen> yes, they will do the same thing. So I guess I can remove them from the querying?
<FromGitter> <drujensen> I agree with your second comment
<FromGitter> <drujensen> So the plan was to extend the query builder and then move the functionality over?
<FromGitter> <drujensen> or did you have other intentions for leaving them out of the base?
<FromGitter> <drujensen> like reusing it elsewhere?
<FromGitter> <robacarp> No, it was just not ready to take over
<FromGitter> <drujensen> ok, cool
<FromGitter> <drujensen> just wanna make sure
<FromGitter> <robacarp> 👍🏻
<FromGitter> <drujensen> @robacarp @Blacksmoke16 please review https://github.com/amberframework/granite/pull/290 when you get a chance
<FromGitter> <drujensen> This PR adds the new query builder that @robacarp created. You can create queries similar to rails with `User.where(name: “John”)`
<FromGitter> <drujensen> or `User.where(:name, :like, :”John*”)`
<FromGitter> <drujensen> you can build up a query with multiple `where` clauses chained
<FromGitter> <drujensen> We also have `order`, `limit`, `offset`. I will work on providing `User.join(:comments).on(userid: user.id)` or something like this.
feepbot has quit [Ping timeout: 246 seconds]
feepbot has joined #amber
<FromGitter> <Blacksmoke16> 👍 will do
<FromGitter> <Blacksmoke16> wasnt this limited to mysql only or something?
<FromGitter> <Blacksmoke16> ah got updated in last PR, nvm
_whitelogger has joined #amber
vivus has joined #amber
<FromGitter> <kingsleyh> hello - I've recently been doing some work on RethinkDB - I wrote these 2 libraries: https://github.com/kingsleyh/crystal-rethinkdb and https://github.com/kingsleyh/kemal-session-rethinkdb and I was thinking about having an ORM for RethinkDB - when I came across Granite - does anyone know if or how I could write an adapter for Granite to work with RethinkDB?
<FromGitter> <kingsleyh> looking at the existing adapters it doesn't look too hard: https://github.com/amberframework/granite/tree/master/src/adapter
<FromGitter> <Blacksmoke16> yea it would be doable
<FromGitter> <drujensen> Hi @kingsleyh I saw your example with Kemal. very cool
<FromGitter> <drujensen> I am not sure if an ORM is the best for NoSQL dbs. Relationships become interesting. You are obviously more than welcome to try it out. Would love to see if the adapter pattern works
<FromGitter> <Blacksmoke16> oo NoSQL
<FromGitter> <Blacksmoke16> it doesnt use SQL so not sure how that would work
<FromGitter> <Blacksmoke16> i never heard of it :/
<FromGitter> <drujensen> well, in theory, if you can create an adapter that handles the following abstract class
<FromGitter> <drujensen> you should be able to make it work
<FromGitter> <drujensen> Is your driver compatible with DB::Database?
<FromGitter> <drujensen> you mainly need to handle select, insert, update and delete to function
<FromGitter> <drujensen> there is an import as well
<FromGitter> <drujensen> you obviously wouldn’t use the query builder functionality
_whitelogger has joined #amber