Two requests

[andrielfn]

When we try fetch some extra information about any movie, we made two requests. :fire:

For example: when we call TMDb::Movie.find(123).images, we made a request for TMDb::Movie.find(123) and another for .images. This is really bad.

We can solve this making the request only when we call to some movie attribute, so if we call TMDb::Movie.find(123) it won't make the request.

Do I make myself clear?

(english review?)

[fernandomantoan]

So, which data is fetched when find() is called?

[lucasalencar]

Do you mean make lazy requests? When you want the whole information about a movie with that id, what should be called?

I think that a way to optimize the request is to make specific methods for specific requests, like the image attribute.

[andrielfn]

@fernandomantoan http://docs.themoviedb.apiary.io/#movies, see GET /3/movie/{id}.

@lucasandre Exactly. For whole information about a movie we should call TMDb::Movie.find(123). Look at link above.

I'm doing what ActiveRecord does: when we try execute some query with People.find(123), per example, ActiveRecord doesn't make the query until we call any attributes of it.

person = Person.find(123) # does't touch the database
person.name # does the query

Specific methods you mean something like TMDb::Movie.images(123)? To me it is really ugly.

What I have in mind:

movie = TMDb::Movie.find(123) # does't fetch, just create a "relation" with ID
movie.original_name # already fetched? no. so fetch the whole information
movie.imdb_id # already fetched? yes. so just return the info

movie.images # fetch the movie images, wich is a specific endpoint

[lucasalencar]

Ok @andrielfn. Thinking this way, I kind of agree with you. Though, I thought you were going to fetch just the specific attribute when it is called, not the whole object. Anyway, if the ActiveRecord does it this way, I think that's a good choice for the project.

[andrielfn]

With a little effort we can do it. :smile:

[lucasalencar]

That is what I was thinking. I think that depending on the case, it's not worth it implementing it.