I just tried an implementation of DeclarativeVersion that uses bulk_create
for all content units, content artifacts, and remote artifacts.
The content units are incompatible with bulk_save(). When trying to save a
batch of content units with bulk_save it raises: ValueError: Can't bulk
create a mu
On Thu, Jun 21, 2018 at 4:19 PM, Brian Bouterse wrote:
> I'm only considering these changes for the plugin writer API to help
> resolve the performance issues.
>
Cool. +1
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/list
I'm only considering these changes for the plugin writer API to help
resolve the performance issues.
On Thu, Jun 21, 2018 at 4:11 PM, Austin Macdonald
wrote:
> For models, bulk_create seems good to me. Endpoints to kick off tasks like
> sync that use bulk_create seems fine.
>
> Are you also prop
For models, bulk_create seems good to me. Endpoints to kick off tasks like
sync that use bulk_create seems fine.
Are you also proposing we have bulk_create for non-task REST API calls?
Should a user be able to POST a list of dictionaries that becomes a set of
Content? I'm open to it, but it seems
+1
David
On Thu, Jun 21, 2018 at 3:55 PM Brian Bouterse wrote:
> I've run cprofile on some of the sync code for Pulp3 and I've noticed that
> we may have some problems with bulk_create on some of the object types.
>
> Here is a small analysis I did: https://pulp.plan.io/issues/3770#note-2
>
>
I've run cprofile on some of the sync code for Pulp3 and I've noticed that
we may have some problems with bulk_create on some of the object types.
Here is a small analysis I did: https://pulp.plan.io/issues/3770#note-2
As an aside, we don't have a bulk add option for
RepositoryVersion.add_content
A 2.17.0 is being planned with some features and recent fixes.
Here [0] is a release schedule page which outlines some tentative dates,
starting with a dev freeze on July 30 2018.
If this schedule needs to be adjusted, please reply with alternate dates.
[0] https://pulp.plan.io/projects/pulp/wik
Base URLs should never change. That's an expectation that all web
application clients everywhere should be able to rely on. "Cool URIs don't
change." If anything, storing IDs is the worse practice, because that
implies that the client is going to use pre-existing knowledge to locally
build URLs, in
Another way of thinking of it would be: "don't store store this unless you
absolutely know that the base of the URL will never, ever change". Storing
IDs is fine, storing hrefs may potentially not be, because it can change
out from underneath you. I think it's actually a similar concept.
On Thu,
> I'm -1 on going the underscore idea, partly because of the aforementioned
> confusion issue, but also partly because but I've noticed that in our API,
> the "underscore" basically has a semantic meeting of "href, [which is]
> generated on the fly, not stored in the db".
>
> Specifically:
>
>-
10 matches
Mail list logo
