We concentrated on node and term but we should definitely test the File entity.

Comments

clemens.tolboom’s picture

This is a nice issue ... files belong to something. Say

drush entity-read file 1 --fields=fid,uri,uid --yaml
fid = 1
uri = public://field/image/imagefield_hJ8qs6.jpg
uid = 1

tells us it belongs to user 1 ... but to what content type?

drush entity-read node `drush entity-read node` --fields=**/fid --yaml
1.field_image.und.0.fid = 1
3.field_image.und.0.fid = 2

gives us the nids where the files are used. Which is equivalent with

drush sql-query "select * from file_usage"

So we need to render the output of

drush entity-delete file 1 --yaml
0.file.node.1 = 1

which is the result of a call to http://api.drupal.org/api/drupal/includes--file.inc/function/file_delete/7

clemens.tolboom’s picture

Component: Code » Drush-1005480
helmo’s picture

drush entity-delete file 1 should error when the file is used somewhere. This would help to maintain the referential integrity within the site.

A more complex solution would be to offer an alternative interactively.
Adding a usage_count to the output of entity-read is an option to make it visible for a user that the file is used somewhere. But the next question the is to give a reverse lookup of where it is used.

clemens.tolboom’s picture

Running test code

drush devel genu 10
drush er user `drush er user` --fields=**/picture --yaml
drush ed file 11 12 13 14
drush er user `drush er user` --fields=**/picture --yaml

shows deleting user pictures works. But that implies devel or user.module does not call file_usage_add.

Checking http://api.drupal.org/api/drupal/includes--file.inc/function/file_usage_... shows user_update_7013(&$sandbox) and user_save so my guess it's devel_generate.

clemens.tolboom’s picture

clemens.tolboom’s picture

clemens.tolboom’s picture

Project: drush_helmo » Drush Entity
Version: » 7.x-5.x-dev
Component: Drush-1005480 » Code
Assigned: clemens.tolboom » Unassigned

Moved to Drush Entity.

clemens.tolboom’s picture

XRef media.module: #1438668: Programmatically creating files and populating their fields with shows a File migration class.

clemens.tolboom’s picture

ragnarkurm’s picture

Issue summary: View changes

Merge with Drush Fields provides full functionality manipulation of file of image field.
Following operations are available: get (list), add, set, del and count.
Working examples:

drush entity-mod node 1 field_file --add --value=/tmp/a.txt

drush entity-get node 1 field_file 
 Delta    FID    UID MIME                           Created      Size Filename
     0     66      1 text/plain           2014-Jul-04 00:03       379 aaa.txt
     1     68      1 text/plain           2014-Jul-04 00:03       379 aaa.txt
     2     69      1 text/plain           2014-Jul-04 00:03       379 aaa.txt
     3     70      1 text/plain           2014-Jul-04 00:04       379 aaa.txt
     4     71      1 text/plain           2014-Jul-11 00:04       379 aaa.txt
     5     72      1 text/plain           2014-Jul-11 00:12       379 aaa.txt
     6     73      1 text/plain           2014-Jul-11 00:33       379 aaa.txt
     7     79      1 text/plain           2014-Jul-15 17:48   2097152 a.txt
     8     80      1 text/plain           2014-Jul-15 17:48   2097152 a.txt
clemens.tolboom’s picture

drush entity-mod node 1 field_file --add --value=/tmp/a.txt
drush entity-get node 1 field_file

I don't see how to bulk add files?
What is weird about the output is that it shows the content of related file entities.

This should be rewritten into

drush entity-update node 1 --fields=field_file --add --field_file=/tmp/a.txt
drush entity-read node 1 --fields=field_file | drush entity-read file 

We could short circuit the latter

drush entity-read node 1 --fields=field_file | drush entity-read file 

into

drush entity-read node 1 --fields=field_file --related-entities

which would provide queries like show the files and author of node 1

drush entity-read node 1 --fields=field_file,author --related-entities

Note drush support output formats which seems broken for 8.x

Hope above is clear enough to make new issues with small patches?

ragnarkurm’s picture

I don't see how to bulk add files?

Sorry, I did not provide how it works adding multiple files.

$ drush entity-del node 1 field_file
Save field data? (y/n): y
$ drush entity-get node 1 field_file
The field is empty.
$ ls -l /tmp/abc/

-rw-r--r--  1 drupal7 drupal7   230 Jul 19 01:40 jack.txt
-rw-r--r--  1 drupal7 drupal7    41 Jul 19 01:39 misc.txt
-rw-r--r--  1 drupal7 drupal7    48 Jul 19 01:39 test.txt

$ drush entity-mod node 1 field_file --add --value=/tmp/abc
Save field data? (y/n): y
$ drush entity-get node 1 field_file

 Delta    FID    UID MIME                           Created      Size Filename
     0     88      1 text/plain           2014-Jul-19 01:55       230 jack.txt
     1     89      1 text/plain           2014-Jul-19 01:55        41 misc.txt
     2     90      1 text/plain           2014-Jul-19 01:55        48 test.txt
ragnarkurm’s picture

Hope above is clear enough to make new issues with small patches?

It will not be a small patch.
it will be the biggest.
File field is most complex amongst popular fields.

Secondly, I wonder why cannot integrate all fields at once, why one by one?

ragnarkurm’s picture

Status: Active » Postponed

drush entity-update node 1 --fields=field_file --add --field_file=/tmp/a.txt

Do you suggest that each field has its own way adding or setting data to it?
For image it will be --field_image for integer it will be --field_number_integer for entity reference it will be --field_taxonomy_term_reference, right?

I suggest to be more user-friendly and use --value regardless of the field type. It also keeps the code and commandline simpler.

Bigger problem is that I run into difficulties having common command (in entity_drush_command()) for updating entity and fields. Only common factor is the name of command. But not further. They operate very differently. The usage (see drush --entity-mod --help or drush --fields-mod --help) is quite massive already, did you check? It is generated dynamically from all supported fields. If you suggest to merge drush entity update with it how will it be? I suggest to use separate commands for entity update and specific field update. It will be even difficult to create a good documentation for such command.

There is one more consideration beyond merge (needs separate issue?) - files should actually be added to the system by front-end query. Meaning: drush will invoke piece of code by http://... Then all permissions fall into place in a right way. Otherwise code owner and web server will often be different users and drupal might not be able to handle files properly (for example to delete when needed etc). It means there should be corresponding piece of server-side counterpart code (complimentary module?) for supporting file transfers.

My current code does not have that, I realized that need later. Drush Fields has option to set owner, group and permission by commandline options, but that might not be enough always as these things may require elevated permissions.