Answers.Body: <p>Since you're saving your data in a separate table, you basically need <strong>two fields</strong> within your custom table to help you identify which field &amp; element originally saved the content:</p>
  
  <ul>
  <li>The <strong>element id</strong> (which you're already storing)</li>
  <li>The <strong>field id</strong> (missing from your current setup)</li>
  </ul>
  
  <p>You could even create an index on your custom table that would be a combo of those two fields.</p>
  
  <p>In theory, you should be able to retrieve your data with a combination of the <code>$field-&gt;model-&gt;id</code> and <code>$field-&gt;element-&gt;id</code>.</p>
  
  <p><strong>When saving:</strong></p>
  
  <pre><code>$attr['elementId'] = $field-&gt;element-&gt;id;
  $attr['fieldId']   = $field-&gt;model-&gt;id;
  
  $fieldRecord-&gt;setAttributes($attr);
  </code></pre>
  
  <p><strong>When retrieving:</strong></p>
  
  <pre><code>$fieldRecord = MyPlugin_FieldRecord::model()-&gt;findByAttributes(array(
      'elementId' =&gt; $field-&gt;element-&gt;id,
      'fieldId'   =&gt; $field-&gt;model-&gt;id,
  ));
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-29T04:50:50.480Z
Answers.Text: Thanks for the answer Lindsey, and yes, this is definitely going in the right direction. The fieldtype I'm working on has some complexities that cause issues somewhat unrelated to my actual problem (guzzle request caching issues and having to validate existence in local records and a third party API) but what you've suggested was one of my first workarounds and right now I'm refactoring a chunk of code that works based on the response from the API (which generates a short link) and if I get that part fixed, I'll confirm the final workflow I end up using.
Answers.UserDisplayName: Selvin Ortiz
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-29T04:55:56.683Z
Answers.Text: Great, thanks Selvin! Definitely let me know if this solution works for you, as I'll soon need to implement the same thing on my plugin. :)
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-29T18:52:54.463Z
Answers.Text: Hey Lindsey,  I've accepted your answer because this is the ideal workflow and what you've outlined works. I had other issues becuase of the complexity of the plugin and a bug in guzzle that had me thinking this set up was not working and went around in circles thinking the field id and element id was not enough uniqueness but this setup along with properly namespaced fields and JS buffering works well in pretty much any situation where multiple intances are needed.
Answers.UserDisplayName: Selvin Ortiz
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-29T18:56:05.490Z
Answers.Text: Awesome, glad to hear you got it working! And thanks for the update!
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-29T04:22:32.740Z
Answers.LastActivityDate: 2014-06-29T19:59:16.603Z
Answers.LastEditDate: 2014-06-29T19:59:16.603Z
Answers.UserDisplayName: Lindsey D
Body: <p>We have a custom fieldtype that can be attached to an entry type multiple times and everything works just fine. This fieldtype has multiple input fields (shortUrl, longUrl) and they have been properly namespaced to make them unique (via the fieldtype handle) and when the data is saved, it gets saved to a table that defines the necessary columns (id, elementId, shortUrl, longUrl) since the <code>defineContetAttribute()</code> method has been set to false.</p>
  
  <p>As previously mentioned, this fieldtype has been properly namespaced and is taking advantage of the Craft JS buffer to avoid naming conflicts.</p>
  
  <p>The issue comes up when we try to retrieve the data from our custom table via <code>preValue($value)</code> because <code>$value</code> will be <code>null</code> and all the other values we have access to in this context  (<code>$field-&gt;model-&gt;id</code>, <code>$field-&gt;model-&gt;handle</code>, <code>$field-&gt;element-&gt;id</code>) are not unique enough to fetch a record.</p>
  
  <p>I've tried a couple of workarounds but have not found a clean way to do this yet.</p>
  
  <p>The <code>prepValue()</code> method provides the entry id (<code>$field-&gt;element-&gt;id</code>) which we can use to fetch the content (record) for each field since we have a relationship set but beyond that, I haven't found any other way to identify each record individually so that I can attach it to the right field instance within the input html.</p>
  
  <p>There might be something simple that I'm missing and thought I would ask: )</p>
  
Tags: <plugin-development>
Title: How can multiple fieldtype instances without a content column be attached to the same entry type and still be uniquely identifiable?
ThreadText: # How can multiple fieldtype instances without a content column be attached to the same entry type and still be uniquely identifiable?
  
  (Asked by: username_0 on 2014-06-29)
  
  We have a custom fieldtype that can be attached to an entry type multiple times and everything works just fine. This fieldtype has multiple input fields (shortUrl, longUrl) and they have been properly namespaced to make them unique (via the fieldtype handle) and when the data is saved, it gets saved to a table that defines the necessary columns (id, elementId, shortUrl, longUrl) since the `defineContetAttribute()` method has been set to false.
  
  As previously mentioned, this fieldtype has been properly namespaced and is taking advantage of the Craft JS buffer to avoid naming conflicts.
  
  The issue comes up when we try to retrieve the data from our custom table via `preValue($value)` because `$value` will be `null` and all the other values we have access to in this context (`$field->model->id`, `$field->model->handle`, `$field->element->id`) are not unique enough to fetch a record.
  
  I've tried a couple of workarounds but have not found a clean way to do this yet.
  
  The `prepValue()` method provides the entry id (`$field->element->id`) which we can use to fetch the content (record) for each field since we have a relationship set but beyond that, I haven't found any other way to identify each record individually so that I can attach it to the right field instance within the input html.
  
  There might be something simple that I'm missing and thought I would ask: )
  
  **Tags:** plugin-development
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2014-06-29. Score: 5 | Accepted answer
  
  Since you're saving your data in a separate table, you basically need **two fields** within your custom table to help you identify which field & element originally saved the content:
  
  * The **element id** (which you're already storing)
  * The **field id** (missing from your current setup)
  
  You could even create an index on your custom table that would be a combo of those two fields.
  
  In theory, you should be able to retrieve your data with a combination of the `$field->model->id` and `$field->element->id`.
  
  **When saving:**
  
  ```
  $attr['elementId'] = $field->element->id;
  $attr['fieldId']   = $field->model->id;
  
  $fieldRecord->setAttributes($attr);
  
  ```
  
  **When retrieving:**
  
  ```
  $fieldRecord = MyPlugin_FieldRecord::model()->findByAttributes(array(
      'elementId' => $field->element->id,
      'fieldId'   => $field->model->id,
  ));
  
  ```
  
  > **Comments:**
  > **username_0**: Thanks for the answer username_1, and yes, this is definitely going in the right direction. The fieldtype I'm working on has some complexities that cause issues somewhat unrelated to my actual problem (guzzle request caching issues and having to validate existence in local records and a third party API) but what you've suggested was one of my first workarounds and right now I'm refactoring a chunk of code that works based on the response from the API (which generates a short link) and if I get that part fixed, I'll confirm the final workflow I end up using.  
  > **username_1**: Great, thanks username_0! Definitely let me know if this solution works for you, as I'll soon need to implement the same thing on my plugin. :)  
  > **username_0**: Hey username_1,  I've accepted your answer because this is the ideal workflow and what you've outlined works. I had other issues becuase of the complexity of the plugin and a bug in guzzle that had me thinking this set up was not working and went around in circles thinking the field id and element id was not enough uniqueness but this setup along with properly namespaced fields and JS buffering works well in pretty much any situation where multiple intances are needed.  
  > **username_1**: Awesome, glad to hear you got it working! And thanks for the update!  
  
  ---
  
  