pydomo - dataset export json.decoder.JSONDecodeError

Hey Everyone,

 

I've been using the new PyDomo libarary in python 3.x and it has been working great... until I try to export a dataset at which point I get:

 File "C:\Users\UserName\Python35\lib\json\decoder.py", line 357, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

 My early hunch is that this is due to the api call returning the data as a bit-string which would need to be converted to a string before being deconded by the json package.

 

Code to reproduce:

from pydomo import Domo
import logging
import json

domo_id = Insert domo api user ID as string here
domo_secret = Insert Domo secret as string here
dataset_id = Insert Dataset ID as string here
destination_path = 'C:\\Users\\Username\\Documents\\test_data.csv'

include_csv_header = True
domo = Domo(domo_id,domo_secret,'api.domo.com',True,'42N',logging.INFO)
csv_file = domo.datasets.data_export_to_file(dataset_id,destination_path,include_csv_header)

 

Has anyone run into anything similar / know if a fix is possible without making changes to the package?

 

Thanks,

Austin

Best Answer

  • anafziger
    anafziger Member
    Answer ✓

    Update:

     

    The error goes away as long as I call the get metadata api before hand, like so:

    from pydomo import Domo
    import logging
    import json

    domo_id = Insert domo api user ID as string here
    domo_secret = Insert Domo secret as string here
    dataset_id = Insert Dataset ID as string here
    destination_path = 'C:\\Users\\Username\\Documents\\test_data.csv'

    include_csv_header = True
    domo = Domo(domo_id,domo_secret,'api.domo.com',True,'42N',logging.INFO)
    dump_meta = domo.datasets.get(dataset_id)
    csv_file = domo.datasets.data_export_to_file(dataset_id,destination_path,include_csv_header)

     

    Only difference I see between the calls is that datasets.get forces a renewal of the token while the datasets.data_export_to_file does not.  Could this be it?

Answers

  • anafziger
    anafziger Member
    Answer ✓

    Update:

     

    The error goes away as long as I call the get metadata api before hand, like so:

    from pydomo import Domo
    import logging
    import json

    domo_id = Insert domo api user ID as string here
    domo_secret = Insert Domo secret as string here
    dataset_id = Insert Dataset ID as string here
    destination_path = 'C:\\Users\\Username\\Documents\\test_data.csv'

    include_csv_header = True
    domo = Domo(domo_id,domo_secret,'api.domo.com',True,'42N',logging.INFO)
    dump_meta = domo.datasets.get(dataset_id)
    csv_file = domo.datasets.data_export_to_file(dataset_id,destination_path,include_csv_header)

     

    Only difference I see between the calls is that datasets.get forces a renewal of the token while the datasets.data_export_to_file does not.  Could this be it?

  • The same thing happened to me.
    It would be nice to fix pydomo.

  • Thanks for sharing this information.

     

    CC @btm  @kamuela please have a look at this post

  • btm
    btm Domo Employee

    @anafziger & @user06158 - I'm the Product manager over our APIs and SDKs. Sorry for the inconvenience.

     

    We'll take a look into the issue with our team and update as soon as possible.

     

    Thanks,

  • Thank you for reply.

    I am looking forward to more great improvment from DOMO.

  • user001021
    user001021 Domo Employee

    This issue was caused by an oversight in automatic authentication. Authentication in pydomo has been revisited and centralized to the "request" function in the Transport class (Transport.py line 54). 

    This fix has been merged into master and published to PyPi. https://github.com/domoinc/domo-python-sdk

     

    Pydomo v0.1.3 is available for install via `pip3 install pydomo --upgrade`

     

    This update has added 'requests_toolbelt' as a dependency, please install it via `pip3 install requests_toolbelt`

  • btm
    btm Domo Employee

    @anafziger@user06158 -

    A quick update that hopefully you'll see in this thread.  We've been able to push out a newer verison of the SDK that should address the issue.

     

    Sorry for the incovenience, we appreciate you pointing out the bug.

     

    Thanks!

This discussion has been closed.