Doctrine Inheritance Mapping - symfony

I have Vehicle and Person classes. I have items that can be assigned to EITHER a person or a vehicle. I looked into inheritance mapping and I am visualizing my assignment table to be the one that would use the inheritance mapping but I'm not sure if I am correct. I would expect my assignment table to look like:
ID | item_id | type (vehicle/person) | entityId (the ID of the vehicle or person)
____ |____________|________________________|_____________________________________________
1 | 1 | person | 1
2 | 2 | vehicle | 1
Can someone explain the correct mapping to use and maybe an example?

Inheritance mapping is for when you have (for example) an Address which could be a Person Address vs. a Business Address. You can have a doctrine Superclass Address that PersonAddress and BusinessAddress inherits from. Doctrine Superclass This isn't the proper approach for your situation.
The proper solution would be to make a ManyToMany (Many people have many items) association from Person to Item and ManyToMany (Many vehicles have many items) from Vehicle to Item. If you don't want and item assigned to both a person and a vehicle, you'll have to work that logic into your controllers.
It's possible to have your Item be sort of the primary object with associations to either a person or vehicle and include the object type. This can and does work, yet it really complicates your application significantly. I've modeled a current project in that fashion, but I had good reason to go that route.

Related

Preventing cycles in a neo4j graph where relationships are dated

Note: I apologize for not being able to include the images directly in the post, I don't have enough reputation in stackoverflow yet.
I'm brand new to graph databases, but I'm trying to understand if a graph database is suited for my problem. Here we go!
I have a set of users who can relate to each other via a "Parent" relationship (i.e., they can be built into a tree / hierarchy). The "Parent" relationship from one user to another is said to "begin" as of a certain date, and the relationship only "ends" if/when another "Parent" relationships exists between the same users and with a later date.
Every user can have <= 1 parent as of any particular date, and can have >=0 children. I.e., at most one parent at a time, and no limit to the number of children.
I've read blog posts dealing with dated relationships, but they don't seem to address this level of complexity:
https://maxdemarzi.com/2015/08/26/modeling-airline-flights-in-neo4j/
https://maxdemarzi.com/2017/05/24/flight-search-with-neo4j/
My challenge:
For a given set of users with existing "Parent" relationships, determine whether a new "Parent" relationship can be added "as of" a certain date WITHOUT creating a cycle anywhere in the timeline.
To help visualize an example, imagine we have four users Alice, Bob, Carlos, and David.
-----------------------------------------
| User | Date | Parent |
|-----------|---------------|-----------|
| Alice | 09/13/2012 | Bob |
| Alice | 04/01/2021 | David |
| Bob | 01/31/2020 | Carlos |
| Carlos | 02/14/2008 | David |
-----------------------------------------
Here is a (highly abstract) picture representing the current state of the data (time flows to the right):
[Initial state of the data as timeline]
https://i.stack.imgur.com/qdcbL.png
So in this example Alice has Bob as a parent from 9/13/2012 until 4/1/2021, at which point she begins to have David as a parent. Bob has no parent until 1/31/2020, at which point he gets Carlos as a parent. Etc.
I need to be able to determine whether an update/insert will create a cycle in the "parent" hierarchy at any point in time. So, for example, I'd like to be able to determine that it would be INVALID to set Carlos's parent to be Alice as of 10/22/2020 because then there would be a cycle in the hierarchy for the period between 10/22/2020 and 4/1/2021 (i.e., Alice-->Bob-->Carlos-->Alice). To help visualize it:
[Invalid addition creates a cycle in the timeline]
https://i.stack.imgur.com/xA2vv.png
But I also need to be able to determine that it would be VALID to set Carlos's parent to Alice as of 10/22/2021, as drawn here:
[Valid addition with no cycles in timeline]
https://i.stack.imgur.com/9u0P4.png
In terms of modeling the data, I started by thinking of two different models.
First:
I tried having my only nodes be "Users," and having my "Parent" relationships include a date in the relationship type. Since the range of dates is huge and the dates themselves are not known in advance, I'm not sure this is a good idea but decided to give it a shot anyway.
Diagram:
[graph diagram with dated relationships]
https://i.stack.imgur.com/ZuPDR.png
Cypher:
CREATE (n0:User {name: "Alice"})-[:P_2012_09_13]->(:User {name: "Bob"})-[:P_2020_01_31]->(:User {name: "Carlos"})-[:P_2008_02_14]->(:User {name: "David"})<-[:P_2021_04_01]-(n0)
Second:
I tried creating "UserDay" nodes to capture the date element, thereby reducing the range of relationship types to only two (i.e., a 1:many "HAS" relationship from User to UserDay, then a 1:1 "P" relationship from UserDay to User).
Diagram:
[graph diagram with user-days]
https://i.stack.imgur.com/W60bp.png
Cypher:
CREATE (n8:UserDay {date: "2021-04-01"})<-[:HAS]-(:User {name: "Alice"})-[:HAS]->(:UserDay {date: "2012-09-13"})-[:P]->(:User {name: "Bob"})-[:HAS]->(:UserDay {date: "2020-01-31"})-[:P]->(:User {name: "Carlos"})-[:HAS]->(:UserDay {date: "2008-02-14"})-[:P]->(:User {name: "David"})<-[:P]-(n8)
Given a source User, destination User, and start date, I need to be able to determine if a cycle would be created in the hierarchy for any time in the timeline.
Carlos, Alice, 10/22/2020 ----> should be invalid
Carlos, Alice, 10/22/2021 ----> should be valid
I've been spinning my wheels reading through neo4j docs and googling, and finally decided to ask my very first question on stackoverflow! Please let me know if you have any questions or if anything I've said is unclear.
Thanks in advance!

Optimize complex scenario in Cucumber

I have been working on an automation project where I have to write cucumber test for search filter. Search filter works dynamically where parameters are nested - next parameter are populated based on previous parameter e.g. On selecting "Subscribers" next parameters in dropdown are "Name", "City", "Network". Likewise, on selecting "Service Desk", parameters in subsequent dropdown are "Status", "Ticket no.", "Assignee". I am using Scenario Outline as below:
Scenario Outline: As a user, I can search records
Given I am on search page
When I search on "<category>" and "<nestedfilter>"
Then I see records having "<category>" category
Examples:
|category |nestedfilter|
|Subscribers |Name |
|Subscribers |City |
|Subscribers |Network |
|Service Desk|Status |
|Service Desk|Ticket no. |
|Service Desk|Assignee |
The filter could be more complex as there could be more nested filters based on previous nested filters.
All I need to know if there could be a more efficient way to handle this problem? For example passing data table to step_definition for which I am not too sure.
Thanks
If you really need the order of your items to be preserved, use a data table instead of a scenario outline.
A scenario outline is a shorthand notation for multiple scenarios. The execution of each scenario is not guaranteed. Or at least it would be a mistake to assume a specific execution order. The order of the items in a data table will not change if you use a List as argument and therefore a lot safer in your case.
A common mistake with Cucumber is to use Scenario Outline and example tables to do some sort of semi-exhaustive testing. This tends to hide lots of interesting things about the functionality being developed.
I would start writing single features for the searches you are working with and explore what those searches are and why they are important. So if we start with your first one we get ...
Note: all of the following assumes a background step Given I am searching
When I search on subscribers and name
Then I should see records for subscribers
and with the second one
When I search on subscribers and city
Then I should see records for subscribers
Now it becomes clear that there is a serious flaw in these scenarios, as both scenarios are looking for the same result.
So what you are actually testing is that
The subscribers search has name and city filters
A subscriber search should return subscriber results
Now you can refactor and get
When I do a subscriber search
Then I should see city, name, network filters
When I do a subscriber search
Then I should only see subscriber results
note: This is already much more efficient as you have reduced the number of scenarios from 3 to 2, and reduced the number of searches you have to do from 3 to 1.
Now I have no idea if this is what you want to do, but this is what your current scenario is doing. However because you are using an Outline and Example tables you can't see this.
The fact that you have a drop-down and nested filters is an implementation detail, which describes how the user is trying to achieve what they want to achieve.
If you think of what you're trying to do as examples of how the system behaves, rather than tests, it might be easier. You're not looking for something exhaustive. You also want your scenarios to be specific, so that you're illustrating them with realistic data and concrete examples. If you would commonly have some typical data available, that's a perfect thing to set up using Background.
So for instance, I might have scenarios like:
Background:
Given I have subscribers
| Name | City | Network | Status | etc.
| Bob | Rome | ABC | Alive | ...
| Sam | Berlin | ABC | Dead | ...
| Sue | Berlin | DEF | Dead | ...
| Ann | Berlin | DEF | Alive | ...
| Jon | London | DEF | Dead | ...
Scenario: First level search
Given I'm on the search page
When I search for Subscribers who are in Rome
Then I should see Bob
But not Sue or Jon.
Scenario: Second level search
Given I'm on the search page
When I search for Subscribers in Berlin on the ABC network
Then I should see Sam
But not Sue or Ann
etc.
The full-system scenarios should be just enough to understand what's going on. Don't use BDD for regression. It can help with that, but scenarios will rapidly become slow and unmaintainable if you try to cover every case. Delegate to integration and unit tests where appropriate (see "the testing pyramid").

Compound Resource IDs versus URL IDs

I have two resources with a strict parent/child hierarchical relationship, where the child has no existence without the parent, and where the child ID must be a monotonically increasing integer starting from 1 within the parent resource, so not unique within the global resource set. Lets call them Foo and Bar, where Foo is the parent:
Foo: ABC
|- Bar: 1
|- Bar: 2
|- Bar: 3
Foo: QWE
|- Bar: 1
|- Bar: 2
Within the database, we store this in a table with a simple compound natural key:
Foo | Bar | Value
===================
ABC | 1 | shizzle
ABC | 2 | bizzle
ABC | 3 | fizzle
QWE | 1 | lorem
QWE | 2 | ipsum
The standard requires that the Type / ID combination must be unique within the api to allow included resources to be correctly linked to, so to create a unique Bar ID here we would have to join the compound key as say Foo_Bar, i.e. ABC_1 and QWE_1. Ugly and bringing some issues around the client needing to have knowledge of the key composition and the joining char, but fair enough, and we can always add the natural key as either data or meta for the client to use instead.
My question comes with the url for the child resource. For internal consistency with the document ID, the url might look like:
https://example.com/api/v1/foos/ABC/bars/ABC_1
but that seems rather redundant repeating the 'ABC', not to mention ugly, and inconsistent with our main website urls. I'd much prefer using:
https://example.com/api/v1/foos/ABC/bars/1
I think I'm free to do what I want, but I suspect this may cause issues for some of the libraries out there if they make the assumption that they are the same? In general are urls required to have any logical relationship to the internal Resource Type/ID?
Related to this, can the Resource ID use a '.' to join the composite key instead of a '_'? This would make it consistent wth the relationship paths, so 'foos.bars' = 'ABC.1'. While the standard prohibits '.' in member names, there seems to be no such constraint on ID names?
Cheers!
John.
The specification is not absolute on the format url. Thought it recommends that urls match the resource's id.
From http://jsonapi.org/recommendations/#urls-individual-resources
Treat collections of resources as sets keyed by resource ID. The URL for an individual resource can be formed by appending the resource’s ID to the collection URL.
For example, a photo with an ID of "1" will have the URL:
/photos/1
Following this, your url to access the foo resource with id ABC_1 would be
https://example.com/api/v1/foos/ABC_1
and accordingly to get the bar resource with id 1
https://example.com/api/v1/bars/1
Regarding your example url https://example.com/api/v1/foos/ABC/bars/ABC_1, while not invalid, you won't find any similar example in the specification similar to resource_type/resource_id/relation_name/relation_id (with 4 nested levels).
The specification recommendation is to have 3 levels, which will return in your case an array of resource identifier objects:
resource_type/resource_id/relation_name
From http://jsonapi.org/recommendations/#urls-relationships
It is recommended that a relationship URL be formed by appending /relationships/ and the name of the relationship to the resource’s URL.
For example, a photo’s comments relationship will have the URL:
/photos/1/relationships/comments

Symfony2, Doctrine2, Entity Mapping

I have three tables such as A, B and C. There is ManyToMany relation from table A to table B.
At the same time Table C stores the relations between table A and B.
I want a connection between the tables. For example i want to print a data in table A which relates with table B. It's ok but when i want to take it to the next level and print a data in table A which relates with table B and which relates in table C, it doesn't consider the second condition.
That's my problem.
For better understanding
A: Tv Shows
B: Actors
C: Roles
I want to display role of an actor who acts in a certain tv show. But it returns me all roles the actor has played before (Including other tv shows). But i want the result to turn me as just one role (just one tv show)
Tv Show (1st filter) > Actor (2nd filter) > Role (Result)
Problem: I can't apply 1st filter to results.
Thanks in advance.
What you want to do is to allow the role table to act as the bridge between shows and actors.
Shows 1:many Roles many:1 Actors
So when you link Show and Actor you specify which role an actor plays for a given show. Drop the Doctrine 2 many to many relation between Show and Actor and replace with two 1:many relations with roles.
After that the queries will be easy.

Database design for complex requirement

I have a table for ticket type, (like new,update,escalate), and they have subtypes (for example new have around 5 subtypes eg. server,access etc).
Now every subtype have different info to be stored..(subtype server needs start date, end date, server name and access needs customer id,access type,confirmation attachment etc).
Basically, every subtype will require diff no.of info... so i want to ask , whether i should create diff table for each subtype...for Server i create a table with 4 column and for access i create a table with 7 col.
Chances are low new subtypes will be required once deployed, but still a possibility, so a new table will be created...
Is going this way the correct thing to do, or any other method is there?
Whether you should create a new table for each subtype depends on the nature of the inheritence. The following rule of thumb applies:
MANDATORY; AND: 1 Table for superclass + all subclasses
MANDATORY; OR: 1 Table for each subclass
OPTIONAL; AND: 1 Table for the superclass, 1 table for all subclasses
OPTIONAL; OR: 1 Table for superclass, 1 table for each subclass
MANDATORY means: every member of the superclass must be a member of a subclass.
AND means: a member of the superclass can be several subtypes
Calculated example: let's say you have a model that contains 1 superclass and 3 subclasses.
The total number of tables you would get for each of the four types of inheritence is respectively: 1, 3, 2, 4

Resources