Jump to content

NotionCommotion

Members
  • Posts

    2,428
  • Joined

  • Last visited

  • Days Won

    10

NotionCommotion last won the day on September 22 2021

NotionCommotion had the most liked content!

Contact Methods

  • Website URL
    http://

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

NotionCommotion's Achievements

Prolific Member

Prolific Member (5/5)

34

Reputation

14

Community Answers

  1. Similarly, if one executes the same provider multiple times, they will receive the same results. I have also read so and recognize that external dependencies add additional dimensions, however, see some benefits of doing so and haven't gotten my head around mock objects. I see your point about issues with yielding the same object, and was thinking of cloning as you suggest. Assuming all agree that I should not attempt to update the database to a given state within the provider but right before actually performing each test.
  2. I wish to test an API whether users with various permissions can perform actions on resources with various access policies. I first envisioned using a provider such as the following, however, quickly found it had at least one major flaw and I am certain more. /** * @dataProvider userResourceProvider */ public function testUserResource(User $user, object $resource, int $expectedHttpStatusCode):void { $client = $this->createClient($user); $client->makeSomeHttpRequest($resource); $this->assertStatusCode($expectedHttpStatusCode); } public function userResourceProvider(): \Generator { $user = new User(); $this->updateUserToInitialState($user); $this->updateDatabase($user); foreach($this->resourceClasses as $resourceClass) { $resource = new $resourceClass(); $this->updateResourceToInitialState($resource); $this->updateDatabase($resource); foreach($this->getResourcePolicy() as $policy) { $resource->setPolicy($policy); $this->updateDatabase($resource); foreach($this->getUserPermission() as $permission) { $user->setPermission($permission); $this->updateDatabase($user); yield [$user, $resource, $this->getExpectedHttpStatusCode($user, $resource)]; } } } } Instead of passing the $user and the $resource in their current states to the test method, it will their last state after the second and third foreach loop which I confirmed using the following. public function someProvider(): \Generator { $obj = new SomeObject(); foreach([4,3,6,1] as $i) { $obj->setIndex($i); yield [$i, $obj]; } } Not only will the state of the objects passed to the test be incorrect, I am almost sure the state of the database storing those objects be incorrect as (I think) all database updates be perform before executing the test methods. Questions: Could/should any portions of modifying the state of the objects and the state of the database be updated in the provider (for instance, updateUserToInitialState and updateResourceToInitialState), or should all be repeated each time within the test method? What are the implications of database transactions when performing tests? Any other common gochas when performing tests on objects of different state?
  3. Actually, I think there is an Option 4, and while it goes down the inheritance path, it doesn't bring all the baggage. Instead of extending some big complicated class, only extend small simple classes which are less likely to require future changes. I also recognize that this solution does as you recommend and uses an intermediary table. Still isn't an alternative to inheritance, but at least makes inheritance less painful. I went back and forth whether Project or ProjectPermissionPolicy should hold the other's PK as neither should exist on its own without the presence of the other. I was going to come up with some awesome abstract Person/Heart analogies, but fortunately decided that when the first rule of thumb doesn't apply, the next rule of thumb should be that the parent table is the one which most logically would be delete. Project - Id (PK) - Data Asset - Id (PK) - Data AbstractPermissionPolicy - Id (PK) - discriminator - Data ProjectPermissionPolicy extends AbstractPermissionPolicy - Id (PK, FK to AbstractPermissionPolicy.id) - resourceId (FK to project.id, delete cascade) AssetPermissionPolicy extends AbstractPermissionPolicy - Id (PK, FK to AbstractPermissionPolicy.id) - resourceId (FK to asset.id, delete cascade) Member - PermissionPolicyId (PK, FK to AbstractPermissionPolicy.Id) - UserId (PK, FK to User.Id) - MemberPermissionData User - Id (PK) - GeneralUserPermissionData - OtherData
  4. Thanks Maxxd, I didn't think of it until you brought it up, but vaguely recall reading some blog awhile ago where they promoted always using an intermediary table. Don't know if I agree with "always", but I do think it helps for some situations. Will give it some thought and definitely consider. Thanks!
  5. Projects and assets act as "document container" and the PermissionPolicy which can be referenced by only 1 project or asset applies to the documents, and right or wrong it isn't desirable to have changes to one container affect another. No concerns about any added work if I ever need to change, but some concerns that it is going against everything I've ever read regarding proper database design. I did a quick google search to make sure I was not just imaging it, and all feverishly state that the FK of the parent table must be stored in child table, and that the parent table is the one which can exists on its own without the presence of the child table. But what do they know, so I pulled out my Simple SQL book to see what Rudy says, and he says that the foreign key goes in the table on the many side of the relationship, and for one-to-ones, it should be the same if it did have a many side (potentially, I misinterpreted the part about one-and-ones, and even if I didn't, he was not as adamant on that part) . Forgetting about my specific use case and a different way of asking this question. Have you ever had the need to move the foreign key from the child table to the parent table? Did you have any issues?
  6. Thanks Maxxd, Glad you didn't totally bash the first schema as it is currently what I am going with! It is just different than anything I've done in the past and I think (thought?) different than what others do, and usually that means I am doing it wrong. Appreciate your response!
  7. I am pretty sure I can guess your table names before I can guess your UUIDs. ULIDs are another option, and while I think they might be less likely to have conflicts than UUIDs (UUIDs have 1 in 1,000,000,000,000,000,000,000 odds of a duplicate), they provide other benefits.
  8. Really hoping to get my dilemma resolved as I have tried to multiple times and it just stays in limbo. I provided more access control detail per request even though my real question relates to how best to allow a single object to have reciprocating relationships to multiple other objects. I recognize that no one has any obligation to help, yet many of you have done so and most of what I know is thanks to you. If there just isn't a good answer, please also let me know that so I may stop searching. I am starting to think that ORMs or at least Doctrine too closely couple the DB schema to the object model, and if I wish to use one, I need to compromise on the database schema or other aspects. Thanks again
  9. I gave a little thought on why I have concerns about my proposed schema changes (Option 1). The problem is I have more concerns about the alternate approaches I could think of (Option 2 and Option 3). Option 1. Object that has/owns a property references that property instead of the other way around. Orphan PermissionPolicy records can exist if no Projects, Assets, etc reference it. Can't delete a Projects, Assets, etc, and cascade delete the PermissionPolicy record. Adds complexity to ensure that a given PermissionPolicy is referenced by only a single Project, Asset, etc. Can't switch from OneToOne to ManyToOne by simply removing the unique constraint. Project - Id (PK) - PermissionPolicyId (FK to PermissionPolicy.Id, UNIQUE) - Data Asset - Id (PK) - PermissionPolicyId (FK to PermissionPolicy.Id, UNIQUE) - Data PermissionPolicy - Id (PK) - RequiredPermissionData Member - PermissionPolicyId (PK, FK to PermissionPolicy.Id) - UserId (PK, FK to User.Id) - MemberPermissionData User - Id (PK) - GeneralUserPermissionData - OtherData Option 2. Unique tables for each entity. I don't care for the duplication. User will have individual collections for each type. Project - Id (PK) - Data Asset - Id (PK) - Data ProjectPermissionPolicy - Id (PK) - ProjectId (FK to Project.Id, CASCADE DELETE, UNIQUE) - RequiredPermissionData AssetPermissionPolicy - Id (PK) - AssetId (FK to Asset.Id, CASCADE DELETE, UNIQUE) - RequiredPermissionData ProjectMember - ProjectPermissionPolicyId (PK, FK to ProjectPermissionPolicy.Id, CASCADE DELETE) - UserId (PK, FK to User.Id) - MemberPermissionData AssetMember - AssetPermissionPolicyId (PK, FK to AssetPermissionPolicy.Id, CASCADE DELETE) - UserId (PK, FK to User.Id) - MemberPermissionData User - Id (PK) - GeneralUserPermissionData - OtherData Option 3. Extend every entity from AbstractBaseEntity. I have a few entities which do use inheritance (i.e. CommonToAllSpecification and CustomUserDefinedSpecification) and I will need to have CommonToAllSpecification joined even though there is no access policy for it. Later adding access control to an entity will require changing the primary keys. AbstractBaseEntity - Id (PK) Project extends AbstractBaseEntity - Id (PK) - Data Asset extends AbstractBaseEntity - Id (PK) - Data PermissionPolicy - Id (PK) - AbstractBaseEntityId (FK to AbstractBaseEntity.Id, CASCADE DELETE, UNIQUE) - RequiredPermissionData Member - PermissionPolicyId (PK, FK to PermissionPolicy.Id, CASCADE DELETE) - UserId (PK, FK to User.Id) - MemberPermissionData User - Id (PK) - GeneralUserPermissionData - OtherData
  10. I am not trying to be vague and the roller coaster example is very close. And while I appreciate your help regarding my approach to access policy, my desire is to determine how best to define the database schema and relate the entity objects. I have provided specific details below and hope that it doesn't distract from what I thought was a simple question regarding modelling using composition instead of inheritance. I have these entities (Project, Asset, Vendor) which have properties and some (Project, Asset, but not Vendor) also act as a container for documents. There are three types of users: AdminUser, InternalUser, and ExternalUser, and internal and external users will typically have different access policies. Admin users have the capability to create the parent entities and specify on a per-record basis the access policy for the parent entity and for the documents which they contain. The access policy for the parent entity determines ability to read and update with possible values ALL/NONE. The access policy for the documents is common to all documents contained in a given parent entity, determines ability to create, read, update, and delete with possible values ALL/OWNER/NONE where OWNER represents the logged on user being the user who created the document (note that create doesn't support OWNER). Both internal and external users may also join as a member to a given parent entity, and their permission policy maybe be modified for the given entity. An example Project is as follows, Asset will look the same, and Vendor will look the same except not have the document permission policies. { "id": "01GFJTS5W4DQGVRD6FT1P5SQNW", "name": "MyProject", "type": "project", "otherProperties": "bla", "internalUserAccessPolicy": { "read_parent": "ALL", "update_parent": "NONE", "create_documents": "ALL", "read_documents": "ALL", "update_documents": "OWNER", "delete_documents": "NONE" }, "externallUserAccessPolicy": { "read_parent": "NONE", "update_parent": "NONE", "create_documents": "NONE", "read_documents": "OWNER", "update_documents": "OWNER", "delete_documents": "NONE" }, "members": [{ "userId": "01GFJTSKMT2VVZF90X89D33S38", "UserPermissionPolicy": { "read_parent": "ALL", "update_parent": "NONE", "create_documents": "ALL", "read_documents": "ALL", "update_documents": "OWNER", "delete_documents": "OWNER" } }, { "userId": "01GFJV47D64FNBRM4YW1HGK49J", "UserPermissionPolicy": { "read_parent": "ALL", "update_parent": "NONE", "create_documents": "ALL", "read_documents": "OWNER", "update_documents": "OWNER", "delete_documents": "NONE" } } ], "documents": [{ "documentId": "01GFJVKAC2CT077865KX97TQVH", "name": "siteplan.pdf", "path": "https://example.com/documents/01GFJV9WV055RZDDYFA4W6MPJC", "owner": "01GFJTSKMT2VVZF90X89D33S38" }, { "documentId": "01GFJV9WV055RZDDYFA4W6MPJC", "name": "drawings.pdf", "path": "https://example.com/documents/01GFJVKAC2CT077865KX97TQVH", "owner": "01GFJTSKMT2VVZF90X89D33S38" } ] } The schema is currently as follows: AbstractResource - id (PK) - name - type - internalUserAccessPolicy (value object) - externallUserAccessPolicy (value object) - otherProperties Project extends AbstractResource - id (PK, one-to-one FK to AbstractResource.id) - otherProperties Asset extends AbstractResource - id (PK, one-to-one FK to AbstractResource.id) - otherProperties User - id (PK) - name Member - resourceId (PK, many-to-many FK to AbstractResource.id) - userId (PK, many-to-many FK to User.id) - userAccessPermission (value object) I am thinking of changing the schema to the following where Project and Asset will now have an AccessPolicy property: ResourceAccessPolicy - id (PK) - discriminator (ResourceAccessPolicy or DocumentAccessPolicy) - internalUserResourceAccessPolicy (value object) - externallUserResourcePolicy (value object) DocumentAccessPolicy extends ResourceAccessPolicy - id (PK, one-to-one FK to ResourceAccessPolicy.id) - internalUserDocumentAccessPolicy (value object) - externallUserDocumentPolicy (value object) Project - id (PK, one-to-one FK to DocumentAccessPolicy.id) - discriminatorCopy (FK to ResourceAccessPolicy.className in order to prevent multiple resources from being associated with the same ResourceAccessPolicy) - otherProperties Asset - id (PK, one-to-one FK to DocumentAccessPolicy.id) - discriminatorCopy (FK to ResourceAccessPolicy.className in order to prevent multiple resources from being associated with the same ResourceAccessPolicy) - otherProperties Vendor - id (PK, one-to-one FK to ResourceAccessPolicy.id) - discriminatorCopy (FK to ResourceAccessPolicy.className in order to prevent multiple resources from being associated with the same ResourceAccessPolicy) - otherProperties User - id (PK) - name Member - accessPolicyId (PK, FK to ResourceAccessPolicy.id) - userId (PK, FK to User.id) - userAccessPermission (value object) Maybe it is obvious that I should do it this way, but I've never done it this way and for unknown reasons, have concerns. While I will gladly accept any access policy specific critique, please also let me know whether there is anything fundamentally wrong with this schema approach and whether I should make any changes.
  11. I like the roller coaster analogy! Yep, the roller coaster access policy is as follows: Giant Dipper Ride with an adult: 36" tall or 6 years old Ride solo: 48" tall or 13 years old American Eagle Ride with an adult: 32" tall or 9 years old Ride solo: 38" tall or 15 years old The Fury Ride with an adult: 38" tall or 5 years old Ride solo: 42" tall or 16 years old And, not just roller coasters, but similar requirements are used for ferris wheels, haunted houses, bumper cars, and carousels which are modelled slightly differently than roller coasters. If the user doesn't meet these requirements, they may take a specialized class specifically for a given ride, and based on the grade they received, the requirements are reduced. I model it as such, but later, there is some new requirement and I find the inheritance prevents the flexibility to make the required changes. So, how should I model it? AbstractRide - id (PK) - minimum_height_with_adult - minimum_age_with_adult - minimum_height_solo - minimum_age_solo - discriminator (roller_coaster, ferris_wheel, etc) - applicableCommonData RollerCoaster extends AbstractRide - id (PK, FK to AbstractRide.id) - applicableData FerrisWheel extends AbstractRide - id (PK, FK to AbstractRide.id) - applicableData HauntedHouse extends AbstractRide... UserTakesRideClass - ride_id (PK, FK to AbstractRide.id) - user_id (PK, FK to User.id) - grade User - id - height - age
  12. Thank you requinix and maxxd, Sorry about the lack of details and misused definitions. "Resource" is just an entity class and "access control" is the required permission needed to access a particular record. In addition, there is a ResourceMember object which is associated with a single User and a single resource object which also has required permission data, and this is the part which I am struggling with. One approach I might take is something like: AbstractResourceUnderAccessControl - id (PK) - discriminator - applicableData ResourceUnderAccessControlOne extends AbstractResourceUnderAccessControl - id (PK, FK to resource_under_access_control.id) - applicableData ResourceUnderAccessControlTwo extends AbstractResourceUnderAccessControl - id (PK, FK to resource_under_access_control.id) - applicableData ResourceMember - resource_under_access_control_id (PK, FK to resource_under_access_control.id) - user_id (PK, FK to user.id) - applicableData But doing it this way paints me into a corner, and would like to consider having each ResourceUnderAccessControl and the associated AccessControl different objects and using composition. But it just seems wrong having all these independent ResourceUnderAccessControl entities having a one-to-one relationship to a single AccessControl entity. In addition to making it more complicated to have the database enforce an AccessControl object to only be associated with a single resource, there is also the concern of later putting another resource under access control and having conflicting IDs, however, for this situation, I am using ULIDs and am not worried about it. While I very much appreciate your specific recommendations and advise how to best solve my immediate access control need, I also very much want to better figure out this generic concept as I have been struggling with it literally for years (composition-over-inheritance-examples, alternatives-to-entity-inheritance, favor-traits-with-interfaces-over-inheritance). Is there anything fundamentally wrong with doing it as I showed in my initial post?
  13. I need certain entity classes (i.e. ResourceUnderAccessControOne and ResourceUnderAccessControlTwo) to have more granular access control, and will need to store applicable for each resource on a per-record basis. I am using Doctrine, and one way to do so is have ResourceUnderAccessControlOne and ResourceUnderAccessControlTwo extend AccessControl, however, there are certain shortcomings with Doctrine and inheritance. As an alternative approach, I am thinking of using a one-to-one between each individual resource class and Acl, however, for no particular reason, I have concerns with this approach. Should I? The following provides a bit more context. I do not believe AccessControl will ever need to directly get the resource tied to it, but the resource will need to directly access its associated AccessControl object. For this schema, ResourceUnderAccessControlOne and ResourceUnderAccessControlTwo can share the same AccessControl which goes against business rules, however, either I can have PHP enforce this rule or add a "type" column to all tables and add the appropriate foreign keys. While "maybe" I shouldn't be implementing access control this way, I would still hope for advise for the stated question. Thanks! AccessControl - id (pk) - applicableDataForAccessControl ResourceUnderAccessControlOne - id (pk, FK to AccessControl.id) - applicableDataforResourceOne ResourceUnderAccessControlTwo - id (pk, FK to AccessControl.id) - applicableDataforResourceTwo
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.