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

TODO #109

Closed
aviau opened this issue Feb 28, 2015 · 23 comments
Closed

TODO #109

aviau opened this issue Feb 28, 2015 · 23 comments

Comments

@aviau
Copy link
Member

@aviau aviau commented Feb 28, 2015

TODO LIST

  • Review the docs
  • Update and test all the tutorials
  • Fix the DataFrameClient and improve coverage (see #108 )
  • Implement more operations (user management, etc.)

DONE

  • Debug UDP support (I couldn't get it working)
  • Fix the SeriesHelper
  • Support writing in batch (see #102)
@dashesy

This comment has been minimized.

Copy link

@dashesy dashesy commented Feb 28, 2015

I have a small working library that plan to make it into Pandas, you can take a look if you want here

@aviau

This comment has been minimized.

Copy link
Member Author

@aviau aviau commented Feb 28, 2015

@dashesy Would you keep me updated on that please? If this is ever merged in pandas I would love to support it in the lib.

nemesisdesign added a commit to nemesisdesign/influxdb-python that referenced this issue Mar 5, 2015
nemesisdesign added a commit to nemesisdesign/influxdb-python that referenced this issue Mar 5, 2015
@areski

This comment has been minimized.

Copy link
Contributor

@areski areski commented Mar 10, 2015

The test coverage on DataFrameClient is quite weak, it might be nice to add this to the TODO.

@aviau

This comment has been minimized.

Copy link
Member Author

@aviau aviau commented Mar 11, 2015

Noted.

@cannium

This comment has been minimized.

Copy link
Contributor

@cannium cannium commented Mar 19, 2015

As I noticed, InfluxDB v0.9 supports clustering. Does influxdb-python supports connecting to multiple hosts(a cluster) now? I think the new version should handle clustering properly.

@gst

This comment has been minimized.

Copy link
Contributor

@gst gst commented Mar 27, 2015

about :

Debug UDP support (I couldn't get it working)

it's (very "simply", with write_points() method) tested in last version.. within class UdpTests.. which could probably be extended with others udp tests more advanced, eventually.

@cannium

This comment has been minimized.

Copy link
Contributor

@cannium cannium commented Apr 2, 2015

I posted a pull request for clustering. Please review.

@gst

This comment has been minimized.

Copy link
Contributor

@gst gst commented Apr 13, 2015

@ReAzem
I was still asking myself why you tagged "so quickly" and more important : why you taggeg with v1.0.0.. (and then after 1.0.1 & 1.0.2)..

we could have had/followed the same (at least major) version than the server.. now it's over unless we delete the tags.. (which I'd vote for but it depends..)

wdyt ?

@aviau

This comment has been minimized.

Copy link
Member Author

@aviau aviau commented Apr 13, 2015

@gst

The versioning of the lib has nothing to do with the versioning of the server. This is not the same project.

I am following the Semantic Versioning spec.

major.minor.patch

Everytime the API breaks: major release
Every new feature: minor release
Every bug patch/fix: patch release

The next tag will be 2.0.0 because we broke the API with ResultSet.

@gst

This comment has been minimized.

Copy link
Contributor

@gst gst commented Apr 13, 2015

The versioning of the lib has nothing to do with the versioning of the server. This is not the same project.

that is a shame ! ;) no kidding ;) Ofcourse there aren't the same project :p but they are quite tightly coupled.. aren't they ?
I find that it's quite often that a client follow the same version (at least major) than the server for which it is the client .. just for the sake of clarity / simplicity..
examples : mysql , postgres , others..

then why did you raised from v0.4.1 to v1.0.0 .. ? we certainly could have had v0.9-rcXX :s

The next tag will be 2.0.0 because we broke the API with ResultSet.

because you already tagged v1.0.0 previously ;) which I still don't see a/the reason actually..

@aviau

This comment has been minimized.

Copy link
Member Author

@aviau aviau commented Apr 13, 2015

I find that it's quite often that a client follow the same version (at least major) than the server for which it is the client

Can't do that and respect semver at the same time. I think semver is more important than this.

then why did you raised from v0.4.1 to v1.0.0 .. ? we certainly could have had v0.9-rcXX :s

I wanted to release to PyPI ASAP because of the influxdb08 sub-module. This was a good time so I released 1.0.0. 1.0.0 should have been released a long time ago, I didn't manage versioning at this time.

See the Semver Specification:

How do I know when to release 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.

@gst

This comment has been minimized.

Copy link
Contributor

@gst gst commented Apr 13, 2015

ok for the Semver spec..

but hell :

How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0.

:| there are people using influxdb-server (but v0.8 then...) and its python-client in production (which should then be influxdb-python v0.4.1 ....) ??

@aviau

This comment has been minimized.

Copy link
Member Author

@aviau aviau commented Apr 13, 2015

:| there are people using influxdb-server (but v0.8 then...) and its python-client in production (which should then be influxdb-python v0.4.1 ....) ??

Yes. See here (hopefully it all worked out for him!):

/pull/99
ChristopherRabotin:
I hope to start using influxdb in prod starting the middle of next week. :D

InfluxDB 0.5.0 was announced as ready for production: http://influxdb.com/blog/2014/03/24/influxdb_v0_5_0_ready_for_production.html

I will absolutely keep respecting the semver spec. I will also never revert a tag. PyPI won't let me do it and its just terrible practice anyways.

@ChristopherRabotin

This comment has been minimized.

Copy link
Contributor

@ChristopherRabotin ChristopherRabotin commented Apr 13, 2015

I confirm, if need be, that I use influxdb python in production.

On Mon, Apr 13, 2015, 21:01 Alexandre Viau notifications@github.com wrote:

:| there are people using influxdb-server (but v0.8 then...) and its
python-client in production (which should then be influxdb-python v0.4.1
....) ??

Yes:

#99
#99
ChristopherRabotin:
I hope to start using influxdb in prod starting the middle of next week. :D

I will absolutely keep respecting the semver spec. I will also never
revert a tag. PyPI won't let me do it and its just terrible practice
anyways.


Reply to this email directly or view it on GitHub
#109 (comment)
.

@gst

This comment has been minimized.

Copy link
Contributor

@gst gst commented Apr 13, 2015

points taken.

PyPI won't let me do it and its just terrible practice anyways

yeah I know.. PyPI is just right in that.

@peterchou91

This comment has been minimized.

Copy link

@peterchou91 peterchou91 commented May 12, 2015

i got a problem ,when i ran an example:
1 from influxdb.influxdb08 import InfluxDBClient
2
3 json_body = [{"name": "cpu_load_short","timestamp": "2009-11-10T23:00:00Z","name":"1"}]
4 client = InfluxDBClient('10.136.108.128', 8086, 'root', 'root', 'example')
5 client.create_database('example')
6 client.write_points(json_body)
7 result = client.query('select * from cpu_load_short;')
8 print("Result: {0}".format(result))
when the program above finished,it prints:
Traceback (most recent call last):
File "test.py", line 8, in
result = client.query('select * from cpu_load_short;')
File "/usr/lib/python2.7/site-packages/influxdb/influxdb08/client.py", line 419, in query
chunked=chunked)
File "/usr/lib/python2.7/site-packages/influxdb/influxdb08/client.py", line 447, in _query
expected_response_code=200
File "/usr/lib/python2.7/site-packages/influxdb/influxdb08/client.py", line 255, in request
raise InfluxDBClientError(response.content, response.status_code)
influxdb.influxdb08.client.InfluxDBClientError: 400: Couldn't find series: cpu_load_short

this is so wired,i can't figure it out,can anybody help me ?
thanks

@ChristopherRabotin

This comment has been minimized.

Copy link
Contributor

@ChristopherRabotin ChristopherRabotin commented May 12, 2015

@peterchou91 you're attempting to read from a time series which does not exist. If you think it exists, can you check that it is indeed called cpu_load_short? To create that time series, all you need to do is write points to it.

BTW, I'm not sure here is the appropriate place to discuss your issue.

@kti-richard

This comment has been minimized.

Copy link

@kti-richard kti-richard commented Sep 1, 2015

Any reason not to be using this module with 0.9.x now ?

@aviau

This comment has been minimized.

Copy link
Member Author

@aviau aviau commented Sep 1, 2015

@richard-kti The module supports 9.0.x.

@brewneaux

This comment has been minimized.

Copy link

@brewneaux brewneaux commented Sep 6, 2015

Should this be updated to use line instead of JSON?

@aviau

This comment has been minimized.

Copy link
Member Author

@aviau aviau commented Sep 7, 2015

Should this be updated to use line instead of JSON?

Already done as of 2.7.0

@brewneaux

This comment has been minimized.

Copy link

@brewneaux brewneaux commented Sep 7, 2015

I must have missed that, my apologies.

@aviau

This comment has been minimized.

Copy link
Member Author

@aviau aviau commented Sep 7, 2015

I was using this issue when doing the transition to 0.9.0 and taking over the repository. I don't think it is useful anymore, as it is turning into a forum. I'll close this.

@aviau aviau closed this Sep 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.