+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.
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. I don't have good ideas though... `endpoint`? (though it's not a full endpoint), `guarded_view_obj`? `view_object`? `view`? :) On Tue, Jul 14, 2020 at 2:21 AM Dennis Kliban <dkli...@redhat.com> wrote: > 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. > > On Mon, Jul 13, 2020, 5:45 PM Brian Bouterse <bmbou...@redhat.com> wrote: > >> 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. >> >> So let's assume we have a simple definition like the one below. Each >> instance stores the policy for one viewset. >> >> class AccessPolicy(BaseModel): >> data = JSONField() >> >> 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: >> https://github.com/pulp/pulp_file/blob/de638519fc02d588f403db4c5cfcca7552543c50/pulp_file/app/viewsets.py#L116 >> >> Idea 1: Add a viewset = CharField(). Have it store values as URLs, e.g. >> /pulp/api/v3/remotes/file/file/. >> Idea 2: Add a viewset = CharField(), and have it store values as >> classpaths, e.g. 'pulp_file.app.viewsets.RemoteFileViewset'. >> >> 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? >> >> 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. >> >> Thanks, >> Brian >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
