I am working on a project to migrate a website from asp.net to drupal architecture. But the site content is very hierarchal and has a lot of references between entities.
for example: each content belongs to a category, and each category belongs to another category section. Now there may be another level of hierarchy even.
I am planning to make use of migrate module for migrating the database content and linking the migrated nodes via a node reference field.
But i am getting stuck with migrate module as i can't find a way to migrate the node reference field anywhere...
can anyone help me out with this...
Actually, it doesnt seem to be that hard .. in 2012. Yes, you have to keep track of source IDs versus import IDs, but the migrate module does this for you, in a neat little table. You can join that table in your source query, and update the node reference field with the nid of the .. referenced node. Ofcourse, the referenced nodes should have already been imported. If they werent, you can run an run an 'update' later and referenced nids get entered based on the latter imports too. In practice:
$query = Database::getConnection(
'default', 'mysourcedb'
)->select(
'mysourcetable','source'
)->fields('source', array(
'id',
'title',
'whatever'
'rel_rec_id'
)
);
$query->leftJoin('migrate_map_relimport','relmap','relmap.sourceid1=source.rel_rec_id');
$query->addField('relmap','destid1','rel_node_id');
The code above assumes you have a 'mysourcedb' with a 'mysourcetable' in it that refers to a 'rel_rec_id', and theres another import called RelImport that imports the rel table that rel_rec_id is refering to; it should have already run (or will run before you run an additional update). Do a migrate-status once you have the RelImport class to make sure the table exists.
To be able to make joins to the 'migrate_map_relimport' table, make sure map tables are written to the source database, not the drupal database. This is not always necessary, but here it is:
$this->map = new MigrateSQLMap(
$this->machineName,
array(
'id' => array(
'type' => 'int',
'unsigned' => true,
'not null' => true,
'alias' => 'source'
)
),
MigrateDestinationNode::getKeySchema(),
'mysourcedb' // connection to use to write map tables
);
and finally, assign the retrieved rel_node_id to your node reference:
$this->addFieldMapping( 'field_rel_node', 'rel_node_id' );
Yay, it is rocket science .. YMMV
As far as I know, you will not be able to do this entirely within the migrate module. You'll have to run a few queries directly in MySQL.
Essentially, you'll have to create an extra field in each content type to house their legacy ID's and an additional field for each legacy reference (in addition to the actual nodereference field). Load all the data into the content types (leave the nodereference field empty). Then once all of the entities are loaded in, you run mysql queries to populate the nodereference fields based on the legacy IDs and legacy reference fields. Once that's done you can safely delete these legacy fields.
Not the most elegant solution, but I've used it many times.
Caveats:
This is for Drupal 6; Drupal 7's fields implementation is totally different AFAIK.
For very large migrations, you might want to do your legacy field deletions through MySQL.
You might also take a look at the code for the Content Migrate module (more information at https://drupal.org/node/1144136). It's for migrating D6 Content Construction Kit (CCK) content to D7 Fields and it's been integrated with the References module.
It won't do what you need out of the box, as you're coming from an ASP.net site instead of a D6 site, but it may provide some clues.
Related
We're rolling out an update to an in-house Drupal installation profile, and one of the menu paths that is used frequently is getting changed. Most of our installations reference that menu path in a shortcut (via the "Shortcut" module in core). In an update hook, we'd like to be able to query for those shortcuts and update them.
It feels like this should be straightforward, but for some reason we're finding it difficult to query for shortcuts by their url. We can query them by title, but that seems fragile (since the title could be different between installations, might be different by localization, etc.).
We tried the following, but this lead to the error message 'link' not found:
// This does NOT work.
$shortcuts_needing_update =
\Drupal::entityTypeManager()
->getStorage('shortcut')
->loadByProperties([
'link' => [
'internal:/admin/timeline-management',
],
]);
// This works, but is fragile.
$shortcuts_needing_update =
\Drupal::entityTypeManager()
->getStorage('shortcut')
->loadByProperties([
'title' => 'My shortcut',
]);
Based on the code in \Drupal\shortcut\Entity\Shortcut::baseFieldDefinitions() and \Drupal\shortcut\Controller\ShortcutSetController::addShortcutLinkInline() it's obvious that Shortcut entities have a property called link that can be set like an array containing a uri key, yet it does not seem possible to query by this property even though it's a base field.
Looking at the database, it appears that Drupal stores the URL in a database column called link__uri:
TL;DR That means that this works:
$shortcuts_needing_update =
\Drupal::entityTypeManager()
->getStorage('shortcut')
->loadByProperties([
'link__uri' => 'internal:/admin/old/path',
]
);
Read on if you want to know the subtle reason why this is the case.
Drupal's database layer uses pluggable "table mapping" objects to tell it how to map an entity (like a Shortcut) to one or more database tables and database table columns. The logic for generating a column name for a field looks like this in the default table mapping (\Drupal\Core\Entity\Sql\DefaultTableMapping):
As shown above, if a field indicates it allows "shared" table storage, and the field has multiple properties (uri, title, etc.), then the mapping flattens the field into distinct columns for each property, prefixed by the field name. So, a Shortcut entity with link => ['uri' => 'xyz']] becomes the column link__uri with a value of xyz in the database.
You don't see this often with entities like nodes, which is why this seems strange here. I'm usually accustomed to seeing a separate database table for things like link fields. That's because nodes and other content entities don't usually allow shared table storage for their fields.
How does the mapping determine if a field should use shared table storage? That logic looks like this:
So, the default table mapping will use shared table storage for a field only under specific circumstances:
The field can't have a custom storage handler (checks out here since shortcuts don't provide their own storage logic).
The field has to be a base field (shortcuts are nothing without a link, so that field is defined as a base field as mentioned in the OP).
The field has to be single-valued (checks out -- shortcuts have only one link).
The field must not have been deleted (checks out; again, what is a shortcut without a link field?).
This specific set of circumstances aren't often satisfied by nodes or other content entities, which is why it's a bit surprising here.
We can confirm this by using Devel PHP to ask the table mapping for shortcuts directly, with code like the following:
$shortcut_table_mapping =
\Drupal::entityTypeManager()
->getStorage('shortcut')
->getTableMapping();
$efm = \Drupal::service('entity_field.manager');
$storage_definitions = $efm->getFieldStorageDefinitions('shortcut');
$link_storage_definition = $storage_definitions['link'];
$has_dedicated_storage = $shortcut_table_mapping->requiresDedicatedTableStorage($link_storage_definition);
$link_column = $shortcut_table_mapping->getFieldColumnName($link_storage_definition, 'url');
dpm($has_dedicated_storage, 'has_dedicated_storage(link)');
dpm($link_column, 'link_column');
This results in the following:
I'm new to drupal. I need to write a module that need to handle user related details.
I'm able to create the module and add the necessery database changes in 'users_field_data' table. by using db_add_field in hook_install()
db_add_field('users_field_data', 'user_office', array(
'type' => 'varchar',
'length' => 255,
'not null' => FALSE,
));
But one thing I noticed when installing some other module from drupal is when a new field is added to the database it saves some values to 'config' table and 'key_value'table.
Is there a way that I add the values to 'config' table and 'key_value' table when creating a new field in an existing table in drupal 8.
Adding fields to existing entities should be done using the field and field storage configuration entities.
Take the following steps to accomplish your goals:
Go to the manage fields page of the target entity (for user you can find the link in the configuration page)
Add the required field in the GUI.
Go to the configuration synchronization page and export the field and field storage configuration for the new field.
The new files should be saved in the config/install directory of your module.
Install the module
The field should be added on install.
I want using drupal for create a website.
it's very important for me to know drupal is support ORM.
and me know that drupal 7.0 and upper using orm but it's not clear for me .
any one can help me completly to know about drupal orm?
thank you.
Drupal 7 doesn't use a real ORM like Doctrine, it uses a proprietary database API as referenced on Drupal.org. So you don't write full SQL statements directly but write it using their API to assemble a query.
So yes it acts as a type of ORM but it's not one that's used outside of the Drupal project.
Examples make things easier: from https://drupal.org/node/310075
Regular SQL:
<?php
$result = db_query("SELECT uid, name, status, created, access FROM {users} u WHERE uid <> 0 LIMIT 50 OFFSET 0");
?>
Drupal DB API:
<?php
// Create an object of type SelectQuery
$query = db_select('users', 'u');
// Add extra detail to this query object: a condition, fields and a range
$query->condition('u.uid', 0, '<>');
$query->fields('u', array('uid', 'name', 'status', 'created', 'access'));
$query->range(0, 50);
?>
In addition to the database abstraction layer mentionned in Steve's answer, Drupal 7+ has provide an Entity API (completed by the Entity API module). It evolved from the the node system, completed by the CCK module, from Drupal 6. It does provide abstraction to store, query and retrieve data using objects, but the Entity API is not an ORM, and it does no attempt to be one.
I am trying to learn how to create a custom content type programmatically from within my module.
However, after uninstalling and reinstalling my module I was getting an error stating that one or more of the fields I was trying to create could not be created because they already exist.
So I went hacking through my databse, removing the content type and all tables that belonged to it.
Same result -- field already exists.
Next I went to the Drupal API website looking for ways to delete fields and field instances, and came across
field_delete_field()
and
field_delete_instance()
I made a php page to try to delete the fields that I had created, only to get an error stating that the table I was trying to delete does not exist.
So I'm kinda stuck -- I can't create the fields because they already exist, and I can't delete them because they don't exist!
BTW the code I was modeling my module after is the code found in the "node_example" section of the Drupal examples module.
Ouch, deleting the database tables manually is never a good idea - Drupal's not that forgiving :)
Just to address the code in your install/enable hook, wrap the field creation in:
if (!field_info_field('field_name')) {
field_create_field(...
}
That will stop the problem happening again. Or if you don't want to do that, make sure the field is deleted in the uninstall/disable hook. Obviously that method would potentially result in data loss.
To address the current problem, follow this process:
Completely uninstall (not just disable) your custom module. If it's in an inconsistent state, just delete its row in the system table.
Delete all traces of the field from the field_config and field_config_instance tables.
Truncate all the cache tables manually (any table beginning with cache_).
Not strictly necessary but clear up any lingering content:
$nids = db_query('SELECT nid FROM {node} WHERE type = :type', array(':type' => 'type'))->fetchCol();
node_delete_multiple($nids);
That ought to do it.
Any time you delete a field, through the UI or programatically you'll need to either run cron or call field_purge_batch() to 'hard' delete the fields as they're only marked for deletion in the first instance.
So here's the scenario:
I am building a series of event websites that need to be separate Drupal-6 installations on the same server. Each uses the same architecture but different URLs and themes.
What I'd like the sites to be able to share is content in 2 content types, teachers and sponsors. So that there would be one database with all the teachers and sponsors that each individual event site could then pull from by means of nodequeues.
So that new teacher nodes and sponsor nodes can be created and edited from within any of the Drupal installations.
It would also be convenient to share a user table as well, but not absolutely necessary.
Any ideas?
Does this help you?
The comments in settings.txt explain
how to use $db_prefix to share tables:
* To provide prefixes for specific tables, set $db_prefix as an array.
* The array's keys are the table names and the values are the prefixes.
* The 'default' element holds the prefix for any tables not specified
* elsewhere in the array. Example:
*
* $db_prefix = array(
* 'default' => 'main_',
* 'users' => 'shared_',
* 'sessions' => 'shared_',
* 'role' => 'shared_',
* 'authmap' => 'shared_',
* );
Another way, although I don't know if that would work, is to create one database per Drupal installation and create in each database a VIEW eg. install1_users, install2_users that refers to one shared table shared_users in a shared database. A carefully constructed view should be updatable just like a normal table.
Sounds like a job for the Domain Access project, a suite of modules that provide tools for running a group of affiliated sites from one Drupal installation and a single shared database. The module allows you to share users, content, and configurations across a number of sites. By default, these sites share all tables in your Drupal installation but the Domain Prefix module allows for selective, dynamic table prefixing for advanced users.
IMHO this is much better than rolling a custom solution which poses considerable complexity and risk of not being able to upgrade your site. See Share tables across instances (not recommended).
There are a couple of ways of doing this.
If it's okay to share a single database, you can use prefixing as follows:
$db_prefix = array(
'default' => 'main_',
'users' => 'shared_',
'sessions' => 'shared_',
'role' => 'shared_',
'authmap' => 'shared_',
);
However, keep in mind that there is a hard limit to the number of tables that a MySQL database can hold. According to this thread, it's 1792. If you suspect that you will reach this limit, you can use this hack/bug.
$db_prefix = array(
'default' => '',
'users' => 'maindb.',
'sessions' => 'maindb.',
'role' => 'maindb.',
'authmap' => 'maindb.',
);
where maindb is another shared database that contains the data that you need. This is not best practice, but it works in Drupal 6 (haven't tested in D7).