jpetrucciani / hubspot3

python3.6+ hubspot client based on hapipy, but modified to use the newer endpoints and non-legacy python
MIT License
147 stars 73 forks source link

Hubspot object content inconsistencies? #69

Open jisson opened 4 years ago

jisson commented 4 years ago

Hi,

After having upgraded to the last version of hubspot3 I find that sometime, when fetching objects from the Hubspot API, i may retrieve dict formatted in different ways regarding objects properties.

Sometimes its the 'hubspot' way of formatting object properties:


{'objectId': 47863442,
 'portalId': 5799819,
 'isDeleted': False,
 'objectType': 'PRODUCT',
'properties': {'name': {'value': "My product name",
   'source': 'CRM_UI',
   'sourceId': None,
   'versions': [{'name': 'name',
     'value': "My product name",
     'source': 'CRM_UI',
     'requestId': 'dcb6af03-4c5e-499a-9448-8c689c4f984a',
     'sourceVid': [],
     'timestamp': 1570095121725}],
   'timestamp': 1570095121725},
  'price': {'value': '115',
   'source': 'CRM_UI',
   'sourceId': None,
   'versions': [{'name': 'price',
     'value': '115',
     'source': 'CRM_UI',
     'requestId': 'dcb6af03-4c5e-499a-9448-8c689c4f984a',
     'sourceVid': [],
     'timestamp': 1570095121725}],
   'timestamp': 1570095121725}
}}

and sometimes I only retrieve key / values (not placed under the properties key):

{
    'id': 28612078,
    'name': 'My product name',
    'price': '115',
}

I think that getting a single product will returns to me an hubspot payload while retrieving all the products will return to me prettified products. It seems to be the same thing for most of clients.

I personally prefer the second format that I find more natural for developers. And it could be great to be able to use this format for both input and outputs.

But what I find disturbing is that not all of the clients methods are returning the object information the same way.

What do you think of that?

jpetrucciani commented 4 years ago

Yeah at the moment there isn't a ton of consistency across all of the clients and their methods. I'd love to standardize this a bit more across the board, but also potentially add prettifying as an optional functionality (similar to what was done here recently).

It would be cool to add functionality to be able to use the prettified representations in inputs as well!

jisson commented 4 years ago

If we are able to define guidelines and goals on this topic I could help :)

Letting the choice to the user regarding the outputs / input could be interesting. But I am afraid that it would be complicated to handle if users have to deal with an optional boolean flag each time they call a client.

Maybe prettify_output (and input?) could be given once for all at the instantiation of the clients?

Regarding the outputs, I am currently dealing with those inconstancies in my code by checking the presence of the properties key in the data returned by the library. Not ideal but it simple and it works well.

jpetrucciani commented 4 years ago

Oh yeah that's a good point! It'd probably be best as a Client level flag, potentially with the ability to override on a per-call basis (as to avoid having two instances of a client, one pretty, one not). It could then also inherit from a top level client and propagate to all of the different clients as properties of the Hubspot3 client.

Language to consider:

Then if we can decide on wording for that, we can slowly start converting all calls to use this new functionality. I'll have a look through to see what is most common so we can understand what the default may need to be, and then perhaps put together a todo list for which clients need to be changed

jisson commented 4 years ago

Sound good to me!

jpetrucciani commented 4 years ago

Sorry I've been a bit stalled on this - I haven't forgotten! Things have been a bit crazy at work recently.

I should be able to get around to this sometime next week!