does it make sense to remove uuid on object fetch?

[jscook2345]

I find that I am constantly unpacking collections of objects by using the .values() argument. This is because the requests come back with a uuid for the object. I'm thinking maybe that is not all that useful after a few months now. What do you think? I know adding values() is not a huge deal, but since we always use it that way, perhaps we should remove it at the source?

Just a few examples.

environments = list(project.environments(slug__in=",".join(environment_slugs), ordering="slug").values())

suites = list(project.suites(slug__in=",".join(suite_slugs), ordering="slug").values())

for t in list(build.tests(environment=e.id,suite=s.id).values()):

[amrohassaan]

I do remember that in very early prototypes of squad client, we experimented with returning a list of objects but then we found it would be slightly challenging to retrieve a single object without iterating/slicing the list in case the client was used in shell and then we decided to make it a dict. @chaws probably remembers this case.

[chaws]

Hum I thought you suggested that @amrohassaan :p

I agree with @jscook2345 , we tend to always use .values(). On the other hand I wouldn't make it just a flat list.

It's been a while I kept this tab open (https://github.com/Linaro/lkft-tools/blob/1129f9399e801439833cf2a36a944471e175f147/lib/lkft_squad_client.py#L110) and I think we can make this available to all models.

What do you guys think?

[amrohassaan]

@chaws yes i have seen this before..it is a good idea to yield on demand.

[jscook2345]

@chaws

I think that would be good as well. Lazy loading imo is almost always a good thing ;)