The State of Ruby ORM
solnic.eu
The State of Ruby ORM
1–10 of 20 posts
Re: The State of Ruby ORM
#2His example
User.where(:active => true).kind_of?(Enumerable)
What's the issue here? If you change it to
User.where(:active => true).all.kind_of?(Enumerable)
Re: The State of Ruby ORM
#3The thing that really grates me is that Datamapper (the ORM) is that all their examples tightly couples the models to the database in direct contravention of the data mapper pattern that gives it its name.
After all the entire point of data-mapper is that your objects don't know the details about how they're stored.
Re: The State of Ruby ORM
#4His example User.where(:active => true).kind_of?(Enumerable) What's the issue here? If you change it to User.where(:active => true).all.kind_of?(Enumerable)
Yeah, I'm not sure I understand that either. The whole point is that with the first example it is NOT an Enumerable yet. You are building, what is essentially, a query object and until you access something that query will not be executed at which point it will be an Enumerable as you point to with the "all" method.
Re: The State of Ruby ORM
#5His example User.where(:active => true).kind_of?(Enumerable) What's the issue here? If you change it to User.where(:active => true).all.kind_of?(Enumerable)
Yeah, I'm not sure I understand that either. The whole point is that with the first example it is NOT an Enumerable yet. You are building, what is essentially, a query object and until you access something that query will not be executed at which point it will be an Enumerable as you point to with the "all" method.
I guess TFAA would like the query under construction to be Enumerable, and Enumerating it to serialize it without needing the `all` indirection. Something similar to LINQ.
In fact, some of Enumerable's messages could even be used to further build the query (e.g. `Enumerable#drop(Integer)` simply bumps the query's offset)
Re: The State of Ruby ORM
#6Earlier quoted context omitted.
Yeah, I'm not sure I understand that either. The whole point is that with the first example it is NOT an Enumerable yet. You are building, what is essentially, a query object and until you access something that query will not be executed at which point it will be an Enumerable as you point to with the "all" method.
I guess TFAA would like the query under construction to be Enumerable, and Enumerating it to serialize it without needing the `all` indirection. Something similar to LINQ. In fact, some of Enumerable's messages could even be used to further build the query (e.g. `Enumerable#drop(Integer)` simply bumps the query's offset)
That makes some sense to me, but technically that object at that point is not an "Enumerable" so you are essentially faking it knowing that it would be once executed.
Is there some significant benefit to it returning true for Enumerable that I'm just missing?
Re: The State of Ruby ORM
#7His example User.where(:active => true).kind_of?(Enumerable) What's the issue here? If you change it to User.where(:active => true).all.kind_of?(Enumerable)
His example is really just silly. ActiveRecord is doing the right thing here, it lets you chain your methods until you do something that requires it to hit the database and actually fetch the data.
Re: The State of Ruby ORM
#8interesting topic, lame explanation
Re: The State of Ruby ORM
#9Earlier quoted context omitted.
I guess TFAA would like the query under construction to be Enumerable, and Enumerating it to serialize it without needing the `all` indirection. Something similar to LINQ. In fact, some of Enumerable's messages could even be used to further build the query (e.g. `Enumerable#drop(Integer)` simply bumps the query's offset)
That makes some sense to me, but technically that object at that point is not an "Enumerable" so you are essentially faking it knowing that it would be once executed. Is there some significant benefit to it returning true for Enumerable that I'm just missing?
> That makes some sense to me, but technically that object at that point is not an "Enumerable"
Why not? An enumerable is anything that can be enumerated, the query object holds the potential of being enumerated, it's just an actual underlying query away but that's of no relevance to the interface. The only reason why it's not "technically Enumerable" at that point is... that it does not implement Enumerable's interface.
> so you are essentially faking it knowing that it would be once executed.
Why would you be faking anything? Is LINQ faking anything when it produces IEnumerable after each "operation"?
> Is there some significant benefit to it returning true for Enumerable that I'm just missing?
Interface simplicity? Workflow simplicity? I see no reason for it not to? Get rid of the useless `all` method?
Re: The State of Ruby ORM
#10His example User.where(:active => true).kind_of?(Enumerable) What's the issue here? If you change it to User.where(:active => true).all.kind_of?(Enumerable)
His example is really just silly. ActiveRecord is doing the right thing here, it lets you chain your methods until you do something that requires it to hit the database and actually fetch the data.
What do you mean?