<div dir="ltr">+1 to idea 1 since the URLs seem to me more stable than class paths. We should not change REST API much but potentially can refactor code in some ways.<br><div><br></div><div>One nitpick, maybe the `viewset` field should have a more generic name, since we don't use viewsets exclusively, we also have separate views, e.g. for orphan cleanup or status.</div><div>I don't have good ideas though... `endpoint`? (though it's not a full endpoint), `guarded_view_obj`? `view_object`? `view`? :)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 14, 2020 at 2:21 AM Dennis Kliban <<a href="mailto:dkliban@redhat.com">dkliban@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Pulp 2 users would definitely be familiar with describing policies in terms of urls. The Pulp 3 REST API already uses the pulp_href field as the primary identifier. You should implement idea 1.</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, Jul 13, 2020, 5:45 PM Brian Bouterse <<a href="mailto:bmbouter@redhat.com" target="_blank">bmbouter@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I need some design input. To store AccessPolicy data in the DB I think we want one Model where each instance is the access policy for a given viewset. I think this would be better than one Model per Viewset which would generate N tables for N viewsets with 1 instance of each which would be very strange and inefficient.</div><div><br></div><div>So let's assume we have a simple definition like the one below. Each instance stores the policy for one viewset.<br></div><div><br></div><div>class AccessPolicy(BaseModel):<br>    data = JSONField()</div><div><br></div><div>So what second field can I add to this that would allow me to relate an instance of this model to a viewset. For example the FileRemoteViewset here: <a href="https://github.com/pulp/pulp_file/blob/de638519fc02d588f403db4c5cfcca7552543c50/pulp_file/app/viewsets.py#L116" rel="noreferrer" target="_blank">https://github.com/pulp/pulp_file/blob/de638519fc02d588f403db4c5cfcca7552543c50/pulp_file/app/viewsets.py#L116</a></div><div><br></div><div>Idea 1: Add a viewset = CharField(). Have it store values as URLs, e.g. /pulp/api/v3/remotes/file/file/.</div><div>Idea 2: Add a viewset = CharField(), and have it store values as classpaths, e.g. 'pulp_file.app.viewsets.RemoteFileViewset'.</div><div><br></div><div>I think Idea 1 makes the most sense because that's how our users think of it. I can't think of a good alternative. What do you think makes the most sense? What alternative ideas should we consider?</div><div><br></div><div>If you have feedback please share it. I need to start into something to get it going tomorrow even if it's just Idea 1 for lack of an alternate proposal.<br></div><div><br></div><div>Thanks,</div><div>Brian<br></div></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" rel="noreferrer" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div></div></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>