On 06/14/2010 06:02 PM, Dennis Gregorovic wrote:
On Mon, 2010-06-14 at 17:24 -0700, Mike McCune wrote:
On 06/14/2010 04:56 PM, Mike McCune wrote:
I pointed out to jortel in this irc conversation:
http://pastie.org/1004640
that when fetching a package with the REST api based on the package's ID
the query looks like:
GET /packages/(u'test_consumerwithpackage', u'1', u'1.2.3', u'1.el5',
u'x86_64',
u'9d05cc3dbdc94150966f66d76488a3ed34811226735e56dc3e7a721de194b42e')/
which is exceedingly nasty and hard as a caller to know what the heck to
construct.
To that end I'm going to switch from this type of ID for Package objects:
- self._id = str((name, epoch, version, release, arch, checksum))
+ self._id = str(uuid.uuid4())
I'm actually considering switching all our objects to use UUIDs for
their primary keys. This means any object could be found with:
/object/{uuid}
which looks like:
GET /packages/1c8838f0-be76-4b62-a0cf-c450a5d618e2/
you can still get packages matching by doing:
GET /packages/?name=some-name&arch=i386
which will also find all matching packages with the params specified.
Thoughts?
Mike
Just pushed the change for Package class. Prad, note the:
test_api.test_consumerwithpackage
test is failing and I left it that way since you are reworking how all
the consumer -> package association goes.
Mike
Will the (name, epoch, version, release, arch, checksum) tuple still be
unique?
yes! we still have unique indexes on those fields.
Will the "GET /packages/?name=some-name&arch=i386" call return
the uuids?
that actually will return the full JSON style document for all the
packages matching, here is an example of just one match:
http://pastie.org/1004734
Mike
--
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650.254.4248
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
