The current implementation of the #all function just returned the first page of entities (100 of them) from Fortnox.
@samuel02 fixed that in #157 by iterating over all the pages and loading all the entities. But we already use #all with the "one page" semantic so we propose this:
The implementation by @samuel02 is augmented så that #all takes a :limit argument that lets you specify how many you want, if not limit is given you will get all of them. We will then have to update our code to use the limit argument and @samuel02 can use the new implementation directly.
Shallow entities
The second part of this discussion has to do with what we get back from Fortnox. The index calls do not return full entities, but limited ones that do not have all the attributes of the full version. The question is how we should handle this.
My initial approach to this was to create a collection class, have it know that the models were not complete and give it methods to instantiate the full versions instead. I'm not sure if this is a good approach ....
My problem with this problem is that it is mainly due to API design issues that Fortnox has. Allowing for the type of collection we are talking about, with automatic upgrade o entities, can lead to seriously expensive requests that are essentially hidden to future developers using the gem.
The other obvious option is to have two models, one for shallow and one for full, and allow the shallow one to upgrade to a full. Or, possibly, let the model know if it is shallow or not and raise exceptions when you try to access attributes on a shallow copy that is only available on a full one.
This is marginally better in my opinion, but still problematic. I think I prefer it better since it makes the hack more obvious to new developers.
So, @felixyz @samuel02 @mbirman @ehannes ... What do you think? How should we package this in a way that it is usable without feeling clunky and transparent at the same time?
ehannes
commented
6 years ago
#allwith limitThe current implementation of the
#allfunction just returned the first page of entities (100 of them) from Fortnox. @samuel02 fixed that in #157 by iterating over all the pages and loading all the entities. But we already use#allwith the "one page" semantic so we propose this: The implementation by @samuel02 is augmented så that#alltakes a:limitargument that lets you specify how many you want, if not limit is given you will get all of them. We will then have to update our code to use the limit argument and @samuel02 can use the new implementation directly.Shallow entities
The second part of this discussion has to do with what we get back from Fortnox. The index calls do not return full entities, but limited ones that do not have all the attributes of the full version. The question is how we should handle this. My initial approach to this was to create a collection class, have it know that the models were not complete and give it methods to instantiate the full versions instead. I'm not sure if this is a good approach ....
My problem with this problem is that it is mainly due to API design issues that Fortnox has. Allowing for the type of collection we are talking about, with automatic upgrade o entities, can lead to seriously expensive requests that are essentially hidden to future developers using the gem.
The other obvious option is to have two models, one for shallow and one for full, and allow the shallow one to upgrade to a full. Or, possibly, let the model know if it is shallow or not and raise exceptions when you try to access attributes on a shallow copy that is only available on a full one.
This is marginally better in my opinion, but still problematic. I think I prefer it better since it makes the hack more obvious to new developers.
So, @felixyz @samuel02 @mbirman @ehannes ... What do you think? How should we package this in a way that it is usable without feeling clunky and transparent at the same time?