First of all Thank You for such great module, EugenMayer! It's really fantastic.
I looked into the code and schema of the module and I don't see why there is two tables, what is the reason for this? Wouldn't it be better to have only one table like this:

  $schema['wysiwyg_imageupload_entity'] = array(
    'description' => 'Stores the inline arguments for a specific image used inline',
    'fields' => array(
      'iid' => array(
        'type' => 'serial',
        'unsigned' => TRUE,
        'not null' => TRUE,
        'description' => 'The inline ID of the field, defined by the database.',
        'no export' => TRUE,
      ),
      'fid' => array(
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE,
        'default' => 0,
        'description' => 'Primary Key: The {files}.fid.',
      ),
      'nid' => array(
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE,
        'default' => 0,
        'description' => 'The {node}.nid associated with the uploaded file.',
      ),
      'vid' => array(
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE,
        'default' => 0,
        'description' => 'Primary Key: The {node}.vid associated with the uploaded file.',
      ),
      'cid' => array(
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE,
        'default' => 0,
        'description' => 'Primary Key: The {comment}.cid associated with the uploaded file.',
      ),
      'temporary' => array(
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE,
        'default' => 0,
        'description' => 'Is this file temporary.',
      ),
      'imagecache' => array(
        'type' => 'varchar',
        'length' => 255,
        'not null' => TRUE,
        'default' => '',
        'description' => 'Current selected imagecache preset',
      ),
      'style' => array(
        'type' => 'varchar',
        'length' => 255,
        'not null' => TRUE,
        'default' => '',
        'description' => 'Current selected style to show the image with.',
      ),
      'title' => array(
        'type' => 'varchar',
        'length' => 255,
        'not null' => TRUE,
        'default' => '',
        'description' => 'Image title.',
      ),
      'alignment' => array(
        'type' => 'varchar',
        'length' => 255,
        'not null' => TRUE,
        'default' => '',
        'description' => 'Defines the alignment of the image',
      ),
    ),
    'primary key' => array('iid'),
    'primary key' => array('vid'),
  );

I see that the code a little bit tricky because of handling different cases - inserting images in comments, nodes and node revisions but may be still it's not bad idea to have only one table like this. For example table term_node in taxonomy module has 3 fields - nid, vid and tid, why don't just follow this fashion of handling nodes and revisions in this module?

Comments

eugenmayer’s picture

eugenmayer commented

actually, i cant see how the current implementation differ from the drupal core ones. Could you rephrase? Thanks

netbear’s picture

netbear commented

Hello, Eugen, sorry for my poor english, I'll try to explain.
In wysiwyg_imageupload module there are 2 tables, wysiwyg_imageupload_entity and wysiwyg_imageupload_entity_revision. In the second of them trere are just 2 fields iid, vid.
I propose to move vid column into the wysiwyg_imageupload_entity table and remove second table at all.
May be I'm wrong, but it seems reasonable.
As a result it could be more simple views integration through the join wysiwyg_imageupload_entity table to node table by vid column.
For example, with currently existing views integration I could not create nodes list (module views type - node, also tried imageupload view type) with some cck fields for the node and field, containing 1 image thumbnail from images, uploaded (or connected through browser) to the node and inserted into the body. I needed such views for main page for example.
Thanks for your work.

eugenmayer’s picture

eugenmayer commented
Status: Active » Closed (works as designed)

one single iid can be in several different vids. Thats why you need the extra table - its the relation of "in what revisions is this iid existing".

Thank cannot be done with one table, otherwise you will copy stuff like preset for the same idd for every vid entry.

Its the same like node and node_revisions