Release 1.10.0?

[rettichschnidi]

I'd love to see a release 1.10.0 happening, as being able to use pip simplifies the distribution of my own software.

Both issues currently assigned for 1.10.0 are resolved. Wondering if there are any other issues which need no be resolved before a new release? Would be willing to help out a bit if need be.

[phanak-sap]

Hi @rettichschnidi.

Answer:

I understand that you want to use your partial-listing feature, even tho it was merged as "experimental, possible subject to change". I have added the enhancement issue to the 1.10.0 milestone as well, since at the moment there is actually no new feature, than this "unofficial" one.

But I will do 1.9.1 bugfix release now, basically just for #194 + #205 bugfixes, but you will be able to use our listing feature in curia_vista project with pip requirements file. I see that your solution with fork is kind of ugly - but be aware that you can have pip install git repository @ specific commit - so you could use your feature in the requirements.txt of curia_vista file right after merging to pyodata master. It is a little less known VCS support of PIP - link; you do not even need to wait for tagged version in git and released package on pypi, while it is certainly the "right way" to do.

E.g. pip install git+https://github.com/SAP/python-pyodata.git@41abb98619aa1

Request on you:

Could you please also do the PR for the documentation and changelog for the partial listing - the commits which were intentionally removed in the end of discussion on 188? I think the practical usage in the curia_vista will add real experience anyway, than just discussion in which we ended in the state described in this comment. Optimistically, we will just merge the new documentation, add the feature to changelog for 1.10.0 and off-we-go. But maybe you will find that you don't want to write while true: if employees.next_url is None as well and maybe we in finding something cleaner anyway :)

Pyodata long term perspective context:

Pyodata support for odata V4 is the one feature that may be potentially breaking backward compatibility - and therefore enforcing 2.0.0 release (especially when combined with the async support currently handled in separate feature branch). I am now more open to just your current partial listing API as official feature in 1.x release.. and again, if the concerns described in the linked comment ends in state that it needs rewrite, add that task to 2.0 milestone as well. This is also open possibility, even if you just hack trough with usage of while : true loops at the moment.

[rettichschnidi]

But I will do 1.9.1 bugfix release now, basically just for #194 + #205 bugfixes, but you will be able to use our listing feature in curia_vista project with pip requirements file. I see that your solution with fork is kind of ugly - but be aware that you can have pip install git repository @ specific commit - so you could use your feature in the requirements.txt of curia_vista file right after merging to pyodata master. It is a little less known VCS support of PIP - link; you do not even need to wait for tagged version in git and released package on pypi, while it is certainly the "right way" to do.

Did not knew about this pip feature - this is awesome, thanks a lot! And for the extra release too!

Could you please also do the PR for the documentation and changelog for the partial listing - the commits which were intentionally removed in the end of discussion on 188? I think the practical usage in the curia_vista will add real experience anyway, than just discussion in which we ended in the state described in this comment.

Will do.

Optimistically, we will just merge the new documentation, add the feature to changelog for 1.10.0 and off-we-go. But maybe you will find that you don't want to write while true: if employees.next_url is None as well and maybe we in finding something cleaner anyway :)

Indeed, this would be very nice. While I could not come up with something better (that is not a potential memory hog or breaks the API), having an example to play around surely helps.

Maybe overkill, but I am toying with the following idea for a while already: curia_vista basically just takes a specific OData 2.0 service, creates an equivalent SQL (PostgreSQL) schema, then fetches all data from the OData service and stores it in the database.

There are two generic aspects, possibly of interest for others too:

1. fetching data as fast as possible from a server (2).
2. convert OData 2.0 schemata to SQL, store received data to the database

The 2nd one would probably justify a separate project and my code ain't too great anyway.

For the first one however, I feel like it would be a good addition to this project (maybe in a 2nd class contrib folder?) because it would...

1. serve as a slightly more complex usage example for new users
2. offer a playground for the partial listing implementation
3. serve as benchmark, become handy when deciding between a threaded (currently the only way to parallelize requests) and an async (feature: Add async networking libraries support  #208) approach

Thoughts?

[phanak-sap]

1.9.1 Released - https://pypi.org/project/pyodata/1.9.1/

For the "fetching data as fast as possible from a server" part - not sure what exactly you want to do, so I would first add it as new .rst documentation (with code sample for benchmarking). Either to advanced.rst page or entirely new one.

Later - maybe add it as integration test or maybe as another script to /bin folder (no need for new contrib folder).

I am considering this issue as resolved.