I have a problem with using the ORM and creating a has and belongs to many self join using Kohana 2.3.4
I have this table
Tasks
ID | Title | etc......
I need to be able to link tasks to other tasks, a task can have multiple children, and multiple parents. So I was thinking of having this table.
Tasks_Tasks
ID | task_1_id | task_2_id
To link the tasks to each other, but I can't work out in Kohana how to set the foreign keys correctly for the relationships, or if it is possible at all?
Can anyone suggest an answer? Or even better, a better solution?
Instead of extending ORM you should be extending ORM_Tree. This is built for just this type of relationship. Take a look at system/libraries/ORM_Tree.php.
Related
I have a problem with 61 join table limit of mysql. I have 57+ different classes extending Base Class which contain association to comments, likes, tags. And MySQL is crashing when i get most commented. Doctrine has to join whole discriminator maps and comments itself and order by COUNT(comments).
Is there way to fix that ?
And is there another way to achieve comments for different types of entities without inheritance and copying same association all over again?
Here is sample schema of Entities. When I want to add new Entity Type with comments,likes I just extends BaseClass to receive these features.
If I understand correctly what you're trying to do is have many different entity types which can be commented on.
First thing to do would be to step back from Doctrine and thing about the simplest table structure you would need to accomplish this.
Something like this may suffice:
Comments
_______________________
| id | type | entity_id |
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
It is nice in Doctrine to have bi-directional relationships in your base class for convenience but sometimes they are not the best choice. Maybe it would simplify your architecture to perform a query directly on the comments table by entity type and id.
You may also want to consider removing the Base class and having each entity be standalone.
Since a blog post can exist in a context where it does not have comments (on a blog that doesn't allow commenting for example) then $blog->getComments() wouldn't make much sense.
Making this change you could do something like this instead:
$comments = $commentsRepository->findCommentsForEntity($entity);
$commentsCount = count($comments);
and the repository could generate the needed query passing the entity as the entity_id parameter and setting the required comment type based on the entity type.
I am trying to add Propel 1.7 to a legacy php project as part of a refactor. I have generated the schema.xml file, and am now adding in the many-to-many relations.
However, there is a table that encodes a three-way many to many relationship, so it has three columns as its primary key, each of which refers to a different id column in a different table.
Basically, websites are a concept defined by a country and a language.
ads_to_websites:
ad_id | country_id | lang_id
refer to
ads->id
country->id
lang->id
Is this supported at all in Propel? I understand how to add foreign keys and primary keys to the schema.xml, but what happens when I want to do a join through the table? Can I use isCrossRef? The documentation is slightly vague, I find.
Or should I make a new table, so that we have
websites:
id | country_id | lang_id
refering to
country->id
lang->id
and
ads_to_websites:
website_id | ad_id
refering to
websites->id
ads->id
Which is possible and I think fits the data model, but a pain to implement (another project uses the same db).
Alternatively, would another ORM like Doctrine do this better?
We are building a core shopping cart that our company will use as a foundation for multiple shopping carts we will build. These are highly specialized, so different product types will require their own tables of data.
For instance, for a cart that sells labels...
product - id | type_id | created
label - id | product_id | x | y | z
We're struggling with how to structure our objects. We'd like to programmatically only interact with the Label class and have the data be "split" so to speak between the two tables. One idea we tossed around was creating a view to use for querying and then just overwriting the object's save() method to actually interact with each table's setters/save functionality.
Has anyone accomplished this or at least faced a similar challenge?
Update: Of course this begs the question... is there a scenario where both tables might have the same column name? And if so, how to handle it.
You can use name/value pair for specialized columns. With "name" part consistent with column names, you can have generalized setter/getter.
Product is related table, so you can interact with it via relation, for instance $labelModel->product. So you have model for each table, as yii suggest. And you can interact only with Label model if you place your functionality at beforeSave(), afterSave() and other methods.
I have a model that contains several types of products that are all stored in different MySQL databases, but all have one "parent" product that is stored in another table. The parent table is called "products" and contains amongst others the variables:
id
type
price
name
An example of "children" would be "books" which would contain amongst others:
id
meta_id
pages
Another "child" could be "dvds":
id
meta_id
tracks
where the meta_id of the child is equal to the id of the parent.
In old fashioned MySQL I would get all books by using:
SELECT
p.id, p.type, p.price, p.name, b.pages
FROM
products p
LEFT JOIN
books b
ON
p.id=o.meta_id
I know how to read & write data to & from one database table using Zend, extending the Zend_Db_Table_Abstract, and using a Mapper & a Model. I'm just not sure how to do this if I have to read/write objects that are stored in multiple database tables. How do I set this up? What model/pattern should I use? I'm sure this is pretty standard stuff, but I been searchjing for days for clear examples, and I just can't seem to figure it out.
I had exactly the same confusion as you, and there is a great page here - Zend Framework Data Models - which explains how to solve this exact problem. You'll see ZF has excellent facilities to handle this sort of thing (short of using an ORM like Doctrine).
Also, when you're querying multiple tables, it is useful to be aware of the integrity check, as mentioned here Zend Framework Db Select Join table help
I need to build a family tree in php and MySQL. I'm pretty surprised at the lack of open source customizable html family tree-building software there is out there, but I digress. I have spent a lot of time reading about storing MySQL digraphs and family trees. Everything makes sense to me: have a table with nodes (people) and a table with edges (relationships).
The only problem I have is I'm not sure of the best way to store relationships that are not necessarily adjacent, for example sibling and grandparent relationships. At first I didn't think this would be a big deal because I can just invisibly enforce a parent (everyone has parents) that would resolve these connections.
However, I also need to be able to store relationships that may not have a common parent such as romantic partners. Everything I have read suggests a parent-child relationship, but since romantic partners do not share a common parent (hopefully), I'm not sure how to store it in the edges table. Should I use a different table, or what? If it's in the same table, how do I represent this? As long as I am doing this with non-familiar relationships, I might as well do it with family too.
To sum up, three questions:
How do I represent lateral relationships?
If a lateral relationship has a common parent, how do I store it? Should this be a family flag on the table where other lateral relationships are stored?
How do I store parent-child relationships where the child is two or more edges away (a grandparent), but the immediate parent is unavailable?
Any help is appreciated, and if anyone has any suggestion for some javascript/html family tree building software, that would be wonderful.
An idea that comes from the Geneapro schema and RootsMagic.
person
------
person_id
name (etc)
life_event_types
----------------
life_event_type_id
life_event_type_description (divorce, marriage, birth, death)
life_events
-----------
life_event_id
life_event_type_id
life_event_description
life_event_date
life_event_roles
----------------
life_event_role_id
life_event_role (mother, father, child)
person_event_role
-----------------
person_id - who
life_event_id - what happened
life_event_role_id - what this person did
So you could have a life event of type "birth", and the role_id tells you who were the parents, and who was the child. This can be extended to marriages, deaths, divorces, foster parents, surrogate parents (where you might have 3 or 4 parents with a very complicated relationship), etc.
As for storing more distant relationships, you can calculate these. For example, you can calculate the Father of anybody by getting the person who has the 'father' role with a matching event_id. You can then get the father of that person, and you have the grandfather of the original person. Anywhere that somebody is unknown, create the person with unknown data.
person
-------
person_id
other_stuff
relation
----------
person_id_1
person_id_2
relationship_type
begin_dt
end_dt
just populate the relationship type with any value you are interested in. (FK to some picklist would be great)
I put the dates on for an interesting subdiscussion/thought provokation.
The GEDCOM data model and the Gramps data model are two of the most popular formats for exchanging geneological data between different tools. Using either of these data models should both (1) make your tool more compatible with other tools and (2) ensure that your data model is compabible with many special cases, considering both data models are specially designed to deal with geneological data.
Tools like Oxy-Gen or the Gramps PHP exporter should get you on your way with respect to how to import GEDCOM data into a database.
For more details, see also my answer to “Family Tree” Data Structure.