Upgrade path from *reference?

+1 i am look for the same thing. any idea there would be a migration path?

yep, We'll likely be putting in an upgrade path, but it definitely won't be for a while yet.

subscribe

Subscribe

...subscribing.

This can be started now, as I think we've got basically everything that we need. I'm not intimately familiar with *reference modules - at least, I'm probably not aware of all the outlying use cases. Let me know if this won't work in some instances.

- Get field instance data, including which types of entities it's attached to, and it'd table.
- Create a relation type with the same name and label as the field, with these options:
- Directional
- Min/max arity = 2
- Source bundles = bundles the field is attached to
- Target bundles = all bundles of the entity type of the reference field: ie. node_reference -> all node bundles
- Add a new relation for each field value (just read through the relevant field table).
- Add a dummy field instance to each bundle that the original field is attached to.
- Remove all instances of the original field.

Seems pretty straight forward, and I think any schema changes from here on in won't really affect it, but would definitely be good to get some feedback from users of *reference modules before starting.

> - Target bundles = all bundles of the entity type of the reference field: ie. node_reference -> all node bundles

This is not necessarily right, as the node reference field can be limited to specific content types allowed for referencing. Perhaps there are other settings in general, that need to be migrated.

If someone would give me a node / user reference with preferably at least a couple thousand references inside that'd be rather helpful. chx1975 at google's excellent mail service finds me. you can share dumps on dropbox, put it online etc. I have a battle plan: write a separate migrate module, grab the name of the node and user reference fields, run a batch, each runs an EntityFieldQuery on those fields uid/nid 0 != , entity_load the results , run relation_create, bliss. Migrate settings as we figure them out. There's not that many settings we support right now. I understand there are access controls which we do not yet have. field_access on the endpoints field FTW however.

Hello chx,

Do you want a complete db snapshot from d6? I have one with 17,000 "real" nodes of various content types and several thousand node references between them. This is from a Northern Territory Land Manager website in Australia.

Cheers,

David

Hm, I was thinking a D7 database. I have zero intentions on writing a D6 migration. That's for the heroic maintainers of CCK.

Subscribe. And, unfortunately, the References module for D7 is only getting its feet on the ground recently (I don't even know if there's a solid upgrade path yet; see #1018580: Upgrade path for nodereference and userreference for D6 > D7 upgrade for more info)... so it's going to be tough to find an already-working site with hundreds, if not thousands, of user/node references.

I, too, am in tsvenson's boat here; I'm excited about this module's potential, but I'll likely develop for now using the References module, as I'm more comfortable with that module's model of references.

Bookmarking for inclusion with the references issues.

Writing a generic update path is not feasible. I can write a MySQL-based upgrade path which will work for 99% of the sites (those that keep field data in MySQL and do not denormalize reference or relation data)

INSERT INTO field_data_endpoints (entity_id, delta, endpoints_entity_id, endpoints_entity_type, endpoints_r_index) SELECT (magic) , 0, entity_id, entity_type, 0 FROM $refence_table
INSERT INTO field_data_endpoints (entity_id, delta, endpoints_entity_id, endpoints_entity_type endpoints_r_index) SELECT (magic)  , 1, target_nid, 'node', 1 FROM $refence_table
INSERT INTO relation (rid, created) SELECT (magic) , UNIX_TIMESTAMP()

approximately this does the update, adjust column names as necessary, add bundle etc. (magic) needs to be a unique value based on a) MAX(rid) before this runs (say $max_rid) b) source_entity_id, source_entity_type, field_name and the target_nid from references. That's one hell of ugly but surely doable.

The reason this won't fly on PostgreSQL because we are messing with the relation.rid sequence -- I guess we could run an ALTER SEQUENCE but I will let someone more familiar with pgsql do it.

Or simpler first copy into a table w/ an autoincrement :)

We need some kind of migration path. For the Drupal 6 users, the migrationpath at the moment is:
CCK-node/user ref -> the reference module, this worked just fine for my sites.
Reference -> relation module, given that we got a working migration path.

I do not care if it's a manual SQL-script based, but it need to be a documented migration path so that not only MySQL ninja's is could pull it off. Since there might never be a direct migration path from CCK-nodref. this is a quite important feature.

Of course, this will be in code , reachable from UI. I have my serious doubts about a D6 path however. I am only interested at this juncture of a D7 upgrade.

If references already includes a d6->7 upgrade path then there is no good reason I can see in providing a d6 cck -> d7 relation direct path..

subscribing

tagging.

I've seen rumors of a lightweight relation field for references-like relations, shouldn't we wait for that before having an upgrade path from references ?

#22 rafamd: no, that's irrelevant. This upgrade path should probably not be thought of as an upgrade path, but a mass-converter. There is, and will remain, a references module, and the two modules have different use-cases (with a lot of overlap). Relation is independent of fields on entities, we don't need to wait for anything. All we need is a d7 db dump with a stack of references from various entities to various other entities (eg. all the ones that are supported by *reference modules).

In fact, this probably shouldn't be a stable release blocker.

I promised @chx I would take a look at this (possibly as its own module?) and there are a few different thoughts. I was thinking we approach the topic from creating a relationDestinationHandler (the destination handler is what will call on relation_create()). So migrate can easily tie into having a relation entity as a destination. The advantage this approach provides is that we can easily introduce approaches to migrate content from any existing reference field (or have dynamic migrations referring the various fields from the UI or drush) or from any other way a developer wishes to bring relationships into relation. I'll be trying to make time over the next month to see what I can get up and running (first duty - create a sandbox ^_^).

As a note, I have created a sandbox for this migration module at http://drupal.org/sandbox/btmash/1492598 (no, I have not yet committed any code). I'll continue to update this issue as I make progress on the module.

Alright, time for an update on this issue. I've been able to get an initial implementation of the migration working. I wrote a prelim destination handler which seems to accept it all just fine. I added in a sample references migration which migrated from a field I had created on my server. At this point, I need to create a dynamic migration that can migrate from fields created by references and entityreference. That will take a bit more time to get up and running (have to figure out when I get some free time) but the hard part is done :)

Thanx Ashok for taking the time to update this issue on the progress you've made while working on it at the same time.

@BTMash: Great to have a destination handler. Thanks for writing this! One question: How do I specify the endpoints?

@nerdcore, as of right now, I'm adding in the fields for the endpoints in the process() function of the import. To do this aspect, I also need to write out an endpoint handler (which will likely end up being my next point of attack though I should see if, when new relations are created, a new endpoint field is created at that time as well). That (or the actual conversion from references to relation) will be my next task (though I'll gladly accept any help I can get to have it all working quickly ^_^).

Linking: #1606404: Migrate integration & upgrade from *reference

Easier to have just one issue.

Added a note on goals.