On Wed, May 23, 2018 at 7:20 AM, Brian Bouterse wrote:
> It sounds like there isn't much blocking this, but does that mean the devs
> should go ahead with planning and making the branching changes?
>
>
Patrick, can we plan to do this next week?
> Also I want to confirm: is the scope of this p
+1 to using _id, _created, and _last_updated only on MasterModel. It looks
like leading underscores for field names are fine:
https://stackoverflow.com/a/25509372 That will resolve this issue. Also
everyone can still use .pk instead of ._id because Django automatically
makes a .pk attribute on ever
On 05/17/2018 07:46 AM, Daniel Alley wrote:
Some content types are not going to be compatible with the normal
sync/publish/distribute Pulp workflows, and will need to be live
API-only. To what degree should Pulp accomodate these use cases?
Example:
Pulp makes the assumptions that
A) the m
Agreed on performance. Doing some more Googling seems to have mixed
opinions on whether UUIDs performance is worse or not. If this is a
significant reason to switch, I agree we should test out the performance.
Regarding the disk size, I think using UUIDs is cumulative. Larger PKs mean
bigger index
The link you sent about bulk_create seems to indicate only that the primary
key attribute on the model doesn’t get set unless you are PostgreSQL. This
ticket seems to confirm this:
https://code.djangoproject.com/ticket/19527
That seems like a big caveat but not a showstopper that would prevent us
On 05/24/2018 11:22 AM, Austin Macdonald wrote:
> I have a few concerns, but they all may be addressable.
>
> 1. URLs and security. If this integer is in the url, it is easy to guess
> other urls. Hopefully, our security model won't depend on obscurity, so
> maybe this isn't much of a concern.
Th
Responses inline.
On 05/23/2018 02:26 PM, David Davis wrote:
> Before the release of Pulp 3.0 GA, I think it’s worth just checking in to
> make sure we want to use UUIDs over integer based IDs. Changing from UUIDs
> to ints would be a very easy change at this point (1-2 lines of code) but
> after
I have a few concerns, but they all may be addressable.
1. URLs and security. If this integer is in the url, it is easy to guess
other urls. Hopefully, our security model won't depend on obscurity, so
maybe this isn't much of a concern.
2. bulk_create. Apparently, bulk_creates would work, but only
