Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#all and shallow entities #160

Open
d-Pixie opened this issue Jun 14, 2018 · 1 comment
Open

#all and shallow entities #160

d-Pixie opened this issue Jun 14, 2018 · 1 comment

Comments

@d-Pixie
Copy link
Member

d-Pixie commented Jun 14, 2018

#all with limit

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
Copy link
Member

ehannes commented Jun 14, 2018

This issue is related to #25

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants