Entity Reference Support

There are several 'entity reference' modules out there that i've run across, however i'm not sure which one is the defacto or going to be the best one to implement.

If there is a particular reference module that you have in mind let me know and i'll investigate what needs to be done in order to support this.

I'll be investigating this very soon, the whole reference thing, and i'll report back what i've found.

With 3.x using Fields it should be fairly simple to add Entity References, can someone test?

I'm fairly certain entity references work.

Drealty > Drealty Property Types > Edit Property Type (bundle of your choosing) > Manage Fields > Add Field > Entity Reference

I was able to select from a wide array of entities to attach to a Drealty bundle. In this case, I selected User, set a user, and saw the data appear in the database. From here, doing association with Views to other entities should be simple (I did this with Agents/Users).

Please let us know if this isnt working for you, I'm pretty confident that it does though.

awesome, glad to hear that it's working!

I'd like to re-open this for a bit of further consideration...

In our MLS (and in most, I would think), we have Agents, Organizations, and Listings. Agents have an org id, orgs have an org id, and listings have an agent and an org id. So it would be super cool to be able to store these relationships with the entity reference field. As is, I think I can get the same result using Rules, by separately storing the IDs for the various entities and then setting up the relation field after saving the entity. But it would be super cool for this to be automatic :).

As is, you can add an entity reference field to any DRealty entity and it works fine, it's just that it doesn't get populated during the import. This shouldn't be expected to work, because entity reference expects an entity ID, but DRealty is giving it the MLS ID when it creates the entity during import. Those aren't from the same set, so it doesn't work. What would be needed would be for DRealty to see that it's an entity reference field, and then do it's own lookup against the entity type given in the field settings to find the Entity ID that matches the MLS ID that's coming in from RETS, and then set that accordingly.

I'll take a look at this if I have some time, for now I'm going to try to set it up via Rules instead.

I agree that an Entity Reference field would be ideal. Have you also considered that the MLS should have relational fields already? For instance, all listings entries have an office ID, and the listing agent's ID, and all agent entries have the office ID field. You could pass those as arguments to a View, or in the URL to an Entity page with a Pathauto URL alias containing the respectie ID.

Yes, I kind of tried to explain that in my previous post... The MLS does provide those fields, and they work fine, but then there's a lot of manual relations require as you described, by using those MLS-based ID's to build views for related agent, office, etc. That's not a super big deal, but since Entity Relation allows you to build relations in Views, things like building a relationship from a listing through to the agent entity so that in one row in a view you could display the property data as well as the listing agent data becomes possible. Without a "real" relation that views is aware of, that's not possible without nesting a view within a view, and that gets pretty scary on the performance side.

I've gone the Rules route for now, which works fine. On my property listing entity I have a Relation field, and also a corresponding MLS ID field. So for instance I have an Office entity relation field (which I don't map to anything with dRealty), and an Office ID field, which is just an integer mapped to the MLS office ID field. I have a rule that runs on entity save that loads the corresponding Office entity for the listing based on the contents of the Office ID field on the listing, sets that office on the Office relation field on the listing, and saves the listing. The result is that the listing then has the office saved as an actual Relation, which means that we get the benefits of having an actual relation... I'm doing the same with Listing Agent, and also the office for an agent, and it seems to work so far...

I think it all boils down to getting the listing entity stable, so we can begin implementing the other resources (Office, Agent).

Once those are in, you could add entity references on those and do some magic with Rules or hook_entity_presave. The big benefit there in my opinion is when you have entity references, you can then use Views or whatever means at your disposal to call up data and render it with a View Mode, like an Agent Profile on a listing.

Office entity types are now implemented, however you'll have to add the entity reference via entityreference module manually in the drealty_import_presave_alter manually as i'm not sure it's going to be possible to do this via an interface.

here's a quick example of how you would go about it:

function mymodule_drealty_import_presave_alter(&$item, $item_context) {
  // only operate on a 'specific' bundle, as this hook is called for the drealty_office entity type as well
  if($item->type == 'residential') {    
    $office_id = db_select('drealty_office', 'do')
                  ->fields('do', array('id'))
                  ->condition('rets_key', $item_context['rets_item']['ListingOfficeUID'])  // ListingOfficeUID is the office id from the RETS class
                  ->execute()
                  ->fetchField();

    //field_office is an entityreference field set to the entity type of drealty_office and bundle of drealty_office
    $item->field_office[LANGUAGE_NONE][0]['target_id'] = $office_id;
  }
}

If anyone knows of a good way to automate this feature w/o having to do it manually i'm all ears!

I just figured out how to set up the relationships between my listings and offices using Entity References, but it looks like from this thread that the references have to be updated manually. Is there still no way to have it add the references automatically during the rets import? I just wanted to verify before deciding how I should handle this for a site I'm building.

you have 'manually' add the code snippet above to allow for the 'automatic' creation of the entity reference during the import process.

hope this clears that up.

Do I just add that code to my template.php?

I also don't think I have "drealty_office" in my database. It looks like the office listings are under "drealty_listing". Is there a special way that I need to add the offices that is different than property listings? Or is this something that just varies from server to server?

Marking as dev and feature request.

We have tried the above snippet from Camidoo but get an error when I try to run the import...

So our question is:

Kevin ~ How do we bond the Drealty Listing and Drealty office content types, in a view so we can show the Drealty office name in the view.

Thanks Toby

Entity references between RETS resources has been captured as a user story for the D8 effort. It doesn't seem it will be implemented in the 7.x version.

I'm reopening this as an internal conversation at Inclind has caused us to believe entity reference is attainable as part of #1951580: Drealty 7.x-3.x roadmap.

Added "Entity Reference" mapping functionality for RETS entities and fields.

E.g., I have a Listing entity, where I want to display the Agent who is to be contacted for this listing information. I have added an EntityReference type field to Listing property (targeting Agent properties).

Within the RETS mapping area, you have a textfield to enter a machine name for the field on the REFERENCED property, which is Agent.
The second field is to select a value based on RETS feed data that will be looked up on the above field.

Patch to be tested, based on the current state of 7.x-3.x-dev branch, is attached.

See: https://www.drupal.org/project/drealty/releases/7.x-3.0-rc1 & https://www.drupal.org/node/1951580#comment-11360001