Relation module storage concept proposal

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

This originates from a discussion between chx, sun, naught101, and dpi and bangpound.

Discussion topic: relation storage, relations-as-entities

Background: relations issue queue

Assumptions and requirements

Assumptions:

  • Relations are fundamentally uni-directional. Directionality can be added on top.
  • Relations are not editable. If you want to edit a relation, delete it, and re-create it.

Assumptions we discussed but have not shared yet (TBD)

  • Will the relationship entity support revisions?
  • Will the relationship entity support translation?

Requirements:

  • Easy lookup from either end of the relation (and from the relation itself) -> relation index table

Three problems we are facing, quite interlinked

  1. How do we enter the relation
  2. How do we display the relation
  3. How do we store the relation

Answering 1) and 2) pretty much determines 3), but answering 3) does not do squat for 1) and 2), so it makes more sense to answer 1, and 2 first.

Proposal

  • Move back to chx's original storage solution - relation index table with two rows per relation, no storage of relation data in fields: (relation_id, entity_id, entity_type, load, ary, predicate) (predicate is related to field_name)
  • chx's dropzone solution (see below)
  • Keep dummy field. This field instances define which bundles can be part of the relation. The field instance settings define the relation bundle, and default settings for new relations. It also allows us to have formatters (which pull data from relation index table, not field storage), and possibly widgets (which allow us to create data in the relation index table, not field storage).
  • Each row in the relation index table contains a "load" flag, describing whether the relation is loaded eg. when the entity is displayed
  • We have another table that defines relation entities, and may include things like directionality flag, source, target, anything else we might want to store about the relation. These entities are fieldable.
  • This means that we need something like a relation-only EFQ

Dropzone in a block

  • block available that catches all entities loaded on the page with hook_entity_load.
  • User selects an entity as one end of a relation (or as one member of an n-ary relation).
  • User uses normal site navigation (eg. search) to find the other entity that they want, block now includes this in loaded entity list. Does not need a separate page that shows the entity just something that loads the entity.
  • User selects this entity as the other end of the relation, and presses "create". Possibly break out to a full page to reorder n-ary relations and select the load flag.
  • Relation is created. Because relation data is not stored in fields, entities on either end do not need to be saved.
  • This solves the problem of finding entities for the autocomplete.

Our assumption was that we relate to entities that are loaded somewhere on the site.
You load it, we relate to it. That's it. - chx

Comments

The beauty of "you load it, we relate it"

naught101's picture

The "dropzone" proposal is just an example of how this concept can work. It can easily be extended to any other interface. For example, if we want an autocomplete widget on a node-edit form, instead of writing custom code to find the appropriate entities to populate a JSON file, we just run a drupal search with the approriate restrictions, and push the outcome of that into a JSON file, and bang, there's our autocomplete list.

Which hooks?

bangpound's picture

Some of this is still confusing, especially when we're using Field API obliquely with "dummy fields" or column-less fields. Given the three problems we're facing, which hooks or APi callbacks do we implement to solve them? And how? To avoid confusion around the word "entity," be concrete: node entity, Relation entity, term entity, etc.

How do we enter the relation?

hook_field_attach_form?
hook_block_*?

How do we display the relation?

hook_field_formatter_view?
hook_entity_view?

How do we store the relation? (how do we load it?)

relation_save?
hook_field_attach_insert?

entity_load?
hook_entity_load?
hook_field_attach_load?

Don't forget: How do we configure the relations?

hook_field_settings_form?
hook_field_instance_settings_form?
hook_field_widget_settings_form?
hook_field_formatter_settings_form?

Answers

chx's picture

Entering a relation has a custom interface. The interface will use hook_block_view, likely hook_menu for the breakout page and finally relation_save().

We store in the relation index table, on hook_field_attach_load inject the entities that are marked as load into the dummy field.

For display, I recommend a default formatter which shows the links to the entities marked to be loaded. Note how this only requires the capability to load the entity and an entity URI callback. We still presume nothing about how the entity is stored. Yummy thing is, we already have the field data! The formatter does not need to know about field dummy-separate table, it's just a formatter.

Configure, that's why we have a dummy field: field_settings_form.

We store in the relation

yched's picture

We store in the relation index table, on hook_field_attach_load inject the entities that are marked as load into the dummy field.

If the action is specific to the 'relation' field type, why not use the 'relation field type' 's hook_field_load() ?

Also, note that hook_field_prepare_view() (for the field type) and hook_field_formatter_prepare_view() (specific to a given formatter's needs) can be useful for late full loading of the referenced entities, just before they are displayed. Doing a full load of the related entities when loading the original object can lead to infinite loops. See taxonomy_field_formatter_prepare_view().

Changes

ginc's picture

in Assumptions:
+ Relations are Fuzzy and not binary. relationships are not black and white, they are gray.
- "Relations are not editable. If you want to edit a relation, delete it, and re-create it." //as it didn't make sense.
+ "Relations are constantly changing through time. e.g. your relationship with your partner getting better or worth."
+ "Changes in some relations can effect other relations. e.g changes in your relationship with one woman will affect your relationship with another woman."

in Requirements:
+"Relations must work with revisions and system must be able to remember how relations changed through time"
- "Relations must work in multi lingual environments"

Added

ginc's picture

+Proposal #2
+ Approach
+ General paths:
+ Maximum use of what we already have in Drupal
+ paths to solve Interlinked problems:
+ 1. How do we enter the relation? -> Use CCK approach
+ 2. How do we display the relation? -> Use Views approach
+ 3. How do we store the relation? -> Use CCK approach

What is going on, GA

dpi's picture

What is going on, GA :S

Relations are Language-agnostic

Relations are not revisioned.

We have agreed on this per discussion.

Seeks clarity on arity.

bangpound's picture

I need a better understanding of the "ary" property in the relation index.

http://en.wikipedia.org/wiki/Arity

The term "arity" is rarely employed in everyday usage. For example, rather than saying "the arity of the addition operation is 2" or "addition is an operation of arity 2" one usually says "addition is a binary operation". In general, the naming of functions or operators with a given arity follows a convention similar to the one used for n-based numeral systems such as binary and hexadecimal. One combines a Latin prefix with the -ary ending; for example:

  • A nullary function takes no arguments.
  • A unary function takes one argument.
  • A binary function takes two arguments.
  • A ternary function takes three arguments.
  • An n-ary function takes n arguments.

http://en.wikipedia.org/wiki/Binary_relation
http://en.wikipedia.org/wiki/Finitary_relation

*math is hard.

@bangpound: u have been so

ginc's picture

@bangpound: u have been so quick to reverse my changes, you didn't let anybody saw them, will not return them for now:
http://groups.drupal.org/node/135804/revisions/280424/view

why did we moved to a wiki page form [#1018408]? so everybody can help improving the proposal.

@dpi: we have to create this module in a way that it function well in a multi language environment. and why in the world u don't want to revision relations???

I think we need to define clearly "what is the result(s) we want to achieve from creating this module?" on the top wiki page
from what i understood by reading the issues, the result is to "Make it possible to relate everything to everything else inside drupal" and to even ideally replace the CCK node reference and user reference.

Excuse me

chx's picture

We moved to a wiki page so the four of us can edit it together. We spent 4-5 hours yesterday getting here. Your ideas are downright crazy with "fuzzy relationships change all the time" -- please write another module for that. I do not even know how to handle such a thing. This is hard enough.

@chx: so please write on top

ginc's picture

@chx: so please write on top your wiki page that u 4 are supposed to edit it! not all ideas that you don't understand are bad after all u may ask for clarification.

@bangpound: u have been so

bangpound's picture

@bangpound: u have been so quick to reverse my changes, you didn't let anybody saw them, will not return them for now:
http://groups.drupal.org/node/135804/revisions/280424/view

GA: I'm sorry I wasn't more clear about why I reverted your changes, and I didn't mean to discredit your input. We are seeking feedback and ideas, but we also want to stay focused on the current proposal. The people who started the wiki page spent almost a year working on and thinking of alternatives. Please present your ideas in comments, and we can discuss and integrate them into the proposal.

I removed "binary" and "fuzzy logic" because I didn't understand what they meant in this context. I think you're describing the "arity" of relations, but I don't know. The terminology in the "relations" discussion is already very complex, and we have a long way to go before we've adequately explained the idea even to each other. I removed your analogies because they don't contribute to a better understanding. We need to keep it concrete and use the same vocabulary.

It may be useful to develop a basic glossary for this project, so we can have productive discussion around a common understanding of the concepts that originate in mathematics.

Reverting on G.D.O is a manual operation, so even though the instructions say to "be bold," I hope everyone with alternative ideas or questions will participate in the discussion in comments before making significant changes to the wiki page. Ultimately, we want to settle on one plan.

@bangpound: As we are

ginc's picture

@bangpound: As we are developing a module for real world use, we have to understand dynamics of relations in real world. in binary logic something is either true or false and there is nothing between. in real word things can be somewhere between true and false; e.g. if you relate some of your friends with the word "important", and look at the situation from binary logic, each of your friends are either important or not; but in the real world of course some of your friends are more important to u. so there is another value that represent how important is your friend to u. so in this situation we can ask u to choose a number between 0 and 100 when you relate a friend to important. that can be easily achieved by adding a field to a relation you define. considering ur plan to make relations field able, u unknowingly already support fuzzy relations.

please tell me why did u remove:
+ "Relations are constantly changing through time. e.g. your relationship with your partner getting better or worth."
+ "Changes in some relations can effect other relations. e.g changes in your relationship with one woman will affect your relationship with another woman."
from assumptions? this is what happens with real world relations.

and please tell me why did u remove:
+"Relations must work with revisions and system must be able to remember how relations changed through time"
+"Relations must work in multi lingual environments"
from requirements?

and finally according to a creation principle, it is very important to understand the end result you want to achieve when you create something new, can you clearly define that?

Importance

sun's picture

so there is another value that represent how important is your friend to u.

That's why relations are fieldable. Every relation starts as a Boolean 0/1 thing, but each type of relation (predicate) can be enhanced with relation-specific fields, if required. That doesn't change the fundamental relationship though, since no matter what the importance value will be, there's still going to be the fundamental relation. And that's why it's important for us to focus on the essential, abstracted components of a relation, how to properly store relations, and how to properly implement the application logic for them.

Daniel F. Kudwien
netzstrategen

I agree with your point sun.

rafamd's picture

I agree with your point sun. The relation use-cases is so vast that it's easy to mess up with the details. I see one of the big challenges is with UI, so why don't we have a set of APIs with the main relation functionality, and leave for sub-modules to extend the UI (allowing different flavors) and other stuff later ??

That's more or less the plan,

naught101's picture

That's more or less the plan, the dropzone block is just an example of one Possible UI. Also, we will probably want to implement one or two basic UIs in core (probably in a sub-module) that are applicable to ALL relations.

A working idea of how it would look

n-tuple's picture

Hi,

I've created a couple of modules on the subject:
http://groups.drupal.org/node/135069

Will be glad to hear your feedback :)

@n-tuple: Thanks for sharing

ginc's picture

@n-tuple: Thanks for sharing it with us, i read all of it. it seems that you researched this topic well, and compared different possible approaches; i want to know you opinion on this question:

What are the cons of storing the relations as CCK fields using multigroups functionality?

multigroups

n-tuple's picture

In my answer i will refer to multigroups as i know it from drupal 6 version. I admit i didn't checked the multigroup functionality at depth but i did saw that current implementation of multigroups is actually not much more than just more natural visual layot of fields. When i look at database i see that eventually data is stored in previous schema, so nothing conceptually new is there.

If you read the pages on my site then you can see that multigroups conceptually can not represent relations, the most we can say about it is that it represents some private cases of relations.

My implementation demonstrates very important and basic relational system parts like: entities, entity set domains and subdomains, the connection to cartezian product and entity set constraint, aggregation (*). Also there are some parts i didn't even mention like relation participation constraints and isa hierarchies (specification/generalization) and their natural constraints which are part of extended ER model.

IMHO, such advanced concepts need to be defined very accuratly:
1. several possible implementations are possible, some more comlex than others, balance should be found between features and complexity
2. implementation should naturally expand/hook into hosting system (drupal in our case)
3. implementation with small system overhead
4. all relation system components (*) must be configurable, this where implementation gets the power from.

IMHO n-tuple modules are the way to go :)

As this page meant to be a

ginc's picture

As this page meant to be a proposal, i created another page to make the big picture clear to every body including myself.

http://groups.drupal.org/node/136079

A couple of points: State and

naught101's picture

A couple of points:

State and rate are different things, but you seem to talk about them the same (relationship is changing <- rate, relationship is now blah <- state). I don't know if this matters to you.

The reason we don't want to use fields as storage (and we've tried, to some extent - look at the module -dev as it currently stands) is that this requires fields values to be added to both relationships on either end of the entity. This means that if you have one entity, say a taxonomy term, and it has 6 billion nodes in it (related to it), then the entity_load() call would have to load all 6 billion.

As far as I can work out, relations a fundamentally language agnostic - that is, if a relation would be different in a different language, then that's probably because it should be relating different entities. I'd like to see a counter example, if anyone has one. For this reason, only the output needs to be internationalisable.

Fuzzy logic is set theory. relations in set theory !== relations in graph theory, which is fundamentally what we're talking about here. That is, we're talking about relations between entities, not between sets. Of course, individual relations can have varying degrees of truth, however they cannot have less than two entities. The degree of truth can easily be stored in a field on the relation. It's also worth pointing out that most use cases won't need this, and that digital storage of fuzzy truth values will never be entirely accurate.

Two quick questions for

ginc's picture

Two quick questions for u:

Did is get it correctly?
Cons of using fields as storage:
1. requires fields values to be added to both relationships on either end of the entity.
2. using entity_load() is very intensive.

Did u consider using Entity API already?
http://drupal.org/project/entity
example of use case: http://drupal.org/project/field_collection

First: No, field values have

naught101's picture

First: No, field values have to be added to both entities on either end of the relation. Loading any entity with a lot of field values is very intensive.

Second: Yep, you'll see that if you look at the currently existing code that entity api is a dependency.

Revisions are important

jtbayly's picture

I can't tell whether it is a done deal that revisions won't be supported, but let me beg for you to consider supporting them.

Relationships do change. A man and woman get married. They are now related. They get divorced. Now they aren't related. But the fact that they used to be related is still very significant. And you still want to be able to know when they were related, and how. Or think of being able to put a friended/unfriended timeline together between two people on Face(stalker)book.

Also, more relationship are added as time progresses. It is important to be able to tell when those various relationships were created so that they can be put into a timeline. Think of being able to put together a timeline of a Face(stalker)book user's friend activity over time.

More technically, what if I want to be able to monitor changes that people have made? Isn't revisions the best way to do that? The relationship between two entities (nodes in D6) is part of the data of those entities. So removing the relationship means that the entity has been changed. Not supporting revisions would mean that I can track all of the data on an entity, except for the relational data from that entity. That doesn't seem right. Let's say that some idiot accidentally deletes a relationship while editing a node. You go view that page later and think, "Hmmm... I think there was a relationship on this node, but I don't have any idea what it was." What are you going to naturally do? Check the revisions, for two reasons: 1. because you want to see what change was made, and 2. you want to see what idiot did it so that you can ban them.

I hope I'm not completely missing something here. Please let me know if I am.

Relationships do change. A

scroogie's picture

Relationships do change. A man and woman get married. They are now related. They get divorced. Now they aren't related.

I think this is a misconception. They are still related, because they were married. The divorce is just the change of a detail of the relationship (sounds awful, I know). So you could have a relation HumanRelationship or something like that, which tells if the couple is married, was married, etc.

The relationship between two entities (nodes in D6) is part of the data of those entities. So removing the relationship means that the entity has been changed

Removing the whole relationship that relates a former couple would be the semantic equivalent of deleting the past marriage, not the equivalence of a divorce, which would only be the change of a field value on the HumanRelationship (which could be tracked on field or entity level).

I knew somebody would suggest that.

jtbayly's picture

I do agree that the divorce relationship could be modeled that way.

However, that doesn't deal with the fact that there are situations where things used to be related, and you'd want to be able to tell that in the system, without keeping them currently related.

I agree that deleting a past relationship doesn't equate to divorce. However, the point still stands. The relationship between two entities is part of the data of those entities. If you delete a relationship, the entity has been changed, and that's the whole purpose behind revisions--tracking changes that have been made to entities.

Saying that revisions don't make sense for relationships between entities is like saying that it's not worth tracking changes to some data in your system. That's simply not true in many instances (including mine). My final example is quite important to consider, and you haven't addressed it yet. One big purpose of revision tracking is so that you can roll-back improper changes. If we refuse to allow that, we are indeed hurting the usability of the module in a huge number of situations.

I'm still not completely convinced I understand what is being proposed, but it seems to me that any argument that claims there is some data that doesn't need to be tracked is an untenable argument. We all agree that relational data is extremely important. (That's why we all want this module.) On what basis is the claim made that relational data is somehow different than all the other data in your system, and therefore doesn't need to be tracked when it changes?

If it is too hard to support revisions, then let's decide to drop support for revisions because they are too hard. But let's not pretend like we are providing an ideal solution if we do that.

I think we might have

scroogie's picture

I think we might have misunderstood each other. As far as I understand it, a relationship itself isn't revisionable, because it does not change. There is an entity for every instance of the relationship that is editable and revisionable to do what you describe. Really "deleting" that entity (meaning that there would be no entity at all related to the relationship instance) should not be possible, it could only be possible to clear the values of the belonging entity to its defaults or something equivalent. This could of course be done with revisions. I see this as logical, because such an entity does not have any reason to exist without being the instance of a relationship. On the other hand, there would be no logical explanation of such a relationship existing without the entity. This is why it makes no sense to "edit" the relationship itself. It does not have any data, it is only a predication, or statement. How would you make this revisionable?

Just as an explanation: I'm not involved in the design or development of the module, I'm just interested because I'd like to leverage the API once its finished.

misunderstanding possible

jtbayly's picture

I also am not involved in the design of development. I just care about it. :) Also, I think you're right. There's a misunderstanding.

Maybe I'm using the word "entity" incorrectly. Is there such a thing as an "entity type"? In D6 I would be talking about content types and nodes. In D7, do we have entities and entity instances?

Just to be clear, let me state my argument in D6 terminology.

Let's say I create 2 content types, and allow them to be related to each other using this module. Then I create 2 nodes--one of each type. Finally, I edit node 1 and relate it to node 2. Later, I edit node 1 again and remove the relationship to node 2. I should be able to see both of those changes in the revision history of node 1. It's as simple as that. If the plans for this module are to support that scenario, I stand corrected, and apologize for wasting everybody's time. If the claim is that it doesn't make sense to track that change, I (still) disagree.

The terminology is difficult

scroogie's picture

The terminology is difficult indeed. I just added the term instance to differentiate between a relationship in an abstract sense and a specific relation of two entities (i.e. nodes).

Is there such a thing as an "entity type"? In D6 I would be talking about content types and nodes. In D7, do we have entities and entity instances?

In the abstract sense, a node type would be a bundle, and the node an entity. As I said, I used "instance" for the specific relationship data. This was probably the wrong choice, as the module creators use the term instance for field instances. Sorry.

Let's say I create 2 content types, and allow them to be related to each other using this module. Then I create 2 nodes--one of each type. Finally, I edit node 1 and relate it to node 2. Later, I edit node 1 again and remove the relationship to node 2. I should be able to see both of those changes in the revision history of node 1.

Someone from the team behind relation might have to chime in here. As far as I understand, this would not be possible with the current solution. Let's say you have nodeA, nodeB and relationA. The module actually stores two statements: "nodeA isPartOf relationA" and "nodeB isPartOf relationA". These statements can be fetched with the node id. They are not part of the node itself, so they don't appear in node revisions. They are a seperate concept stored in a seperate table. Removing the relation will probably delete this statement, which means you won't be able to look up relationA.

Thanks

jtbayly's picture

Your explanation of bundle vs entity is very helpful. I was looking for that info last night.

Also, if you are right about the relationship data not being considered part of the node, I think that's the heart of the problem. It is now impossible to track all the changes that took place on a node. :(

It would be great if the developers could comment and let us know whether we are right. (And if so, I'd love to know why they made this decision, and whether they disagree with my reasoning.)

Storing past relation data

naught101's picture

It's a good point. chx is convinced relations should not be edited, but I'm not entirely. I definitely agree that if a relation changed from joining entityA and entityB to joining entityA and entityC, then that is not a valid case for editing, and the relation should just be deleted and re-created.

Deleting relations is not a problem that we should deal with, I think. It's the same problem as deleting other entities: if some idiot deletes them, then you have no way of knowing who/why/how/when. Tough, sort your user access permissions out properly so it doesn't happen again. That's a core drupal problem (no trash bin)

Re: making relations "past" - if relation entities are editable (but not movable), then it would be quite easy to add some fields like "defunct" and "date of defunction" (hehe). Then all you have to do is make a custom formatter to deal with that data. The other option might be to give relation entities a "current" flag, like the "published" flag on node entities.

I think these problems and solutions don't fundamentally mess with the above proposal, but I'm not entirely sure.

I understand solving the

jtbayly's picture

I understand solving the Drupal problem of deletion is not within the scope of this module. Makes sense. ;)

I guess the central question I have is, do you consider adding a relationship to entity A to be modifying entity A? It sounds like this system will not be making that assumption, which is a problem in my opinion.

In other words, I've realized that my primary concern isn't so much whether the relationship will be revisionable. Rather, I'm concerned that entity A be revised when a relationship is added to it. Is that going to be supported?

I think that is of much greater importance.

re: Does the relation modify

naught101's picture

re: Does the relation modify the entity, possibly, that might depend on the use case. It might be possible to implement something like this over the top of relation, with cck on the nodes, or something.

http://en.wikipedia.org/wiki/Entity-relationship_model seems to be what we're going for, and that model has relations as separate "things" from entities.

To me it seems that if the relations are separate from the entities they link, then it doesn't make sense to revision the entities, because there's nothing changing there.

It would definitely be valuable to make all these concepts as concrete as possible, and I'm pretty sure I'm not thinking along exactly the same lines as you. If you can come up with a couple of use-cases that explain the problems you think exist in the model that would be very much appreciated!

I definitely am a fan of

jtbayly's picture

I definitely am a fan of using the ER model. The inability to create those sort of meaningful data structures in D6 was a real irritation to me in my job. So I'm very excited about what D7 allows, and more particularly what this module in D7 will allow.

Maybe I can explain concretely what my concern is. It's not so much a technical discussion in my mind, but more a usability question. My "thing" is the end-user. I always approach it from their perspective. In this case, that means I'm thinking about this from the content creator or editor's point of view.

From their perspective, the relationship doesn't exist as a separate (standalone) entity. Only a programmer thinks that way. For example there is no such thing as a "performs". Until you have "artist" and "song" on either side of it, "performs" can't even exist.

Now, to the programmer, a "performs" can exist just fine. But relationships exist for a purpose. They add information to the actual entities (artist and song). So the point I'm trying to make is that what is really happening when you create a relationship between two objects is that those two objects are being edited to have more information.

What people are going to do is "edit" the artist to add the song, or "edit" the song to add the artist.

The idea of a dropbox to relate two things is nice, and it could be very useful in certain circumstances. But creating that interface first, reveals the same way of thinking as a programmer. The first interface should let people make the relationship where they are already working, which is in the song and artist, instead of making them create those two things and then go somewhere else and "create" a third thing called a relationship, and then find both of the things they want to relate "again". There is a reason node references and user references are fields in the edit screen of a node.

So, if I've convinced you that conceptually people think of relationships as adding information to (ie editing) pre-existing entities, then you'll understand why I think that it will be people's expectations that when they "edit" an entity to add a relationship, and then save that entity, that a revision of that entity will be created.

end users

naught101's picture

I just asked a friend this:

Imagine that you and I are entities. My entity obviously has properties, like "black hair", and "male". These properties are obviously innately part of my entity. Now imagine there is a relationship between our two entities, "friendship". Is this relationship innately part of either entity? Is either end part innately of either entity?

My friend is not a programmer, but he's a good logical thinker. He wasn't sure, but felt that the answer to both questions is "no", and that it was logical that the relation was separate.

Obviously there are possible ways to edit the artist and add a new song (not previously in the database) with a relation to the artist. This would be something akin to http://drupal.org/project/noderefcreate , which would be relatively easy to implement over the proposed model.

The dropzone is just an example of the process. It's a good example because it makes the mechanism clear. It's obviously not the best UI in the world. See my very first comment for another example.

In other words, no, you haven't convinced me, but yes, obviously we're going to want some good UIs. This proposal is fairly easily suited to making any kind of UI you like including in the node edit form, and is far more versatile, because it doesn't NEED to be in the node edit form.

IMHO, I totally agree with

Seraphin42's picture

IMHO, I totally agree with jtbayly.

For example, I am a sysadmin, and I'm building an intranet to record our architecture, know what is done on our servers, write informations etc ... it's like a wiki but with more functionnalities.

I have several node bundles (content types). One of these bundle is a "server node" with fields like "cpu, ram, disk" etc ...
I want to join another node bundle called "IP". This node contains fields like "public/private, interface" etc ...

Here is the need : Server has many IP, but sometimes, we don't delete an IP, but we assign this IP to another server (node).
It seems to be interesting to have an history to know who/when/why this IP was assigned to another node.

I don't know how it can be introduced, but I hope my need will give you another point of view for this feature.
It's my two cents and I will be happy to contribute by giving feedback of this awesome module.

please red

naught101's picture

please read http://groups.drupal.org/node/135804#comment-455339

Logically and practically, moving an IP to a different server is the same as removing it from the original server, and adding it to the new server.

There is no reason you couldn't set up a "historical connections" relation to keep track of now-extinct relations.

editing

rafamd's picture

It's a good point. chx is convinced relations should not be edited, but I'm not entirely. I definitely agree that if a relation changed from joining entityA and entityB to joining entityA and entityC, then that is not a valid case for editing, and the relation should just be deleted and re-created.

Then, what would be a valid case for editing ? Is there anything else (besides the pointers to the related entities) that could be edited in the relation ?

I assume that all fields added to the relation are a different matter and can be edited, right ?

rafa

Fields yeah

chx's picture

Yes fields can be edited but I can't see a point in editing relations, sorry. if A is married to B then they divorce then that relation no longer exists, if we are storing previously-married then create one such over A and B . And if A marries C then create a relation over A and C. It's not like suddenly B "became" C or somesuch. No, relation endpoints can't be edited.

Relationships & site structuring

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: