We should add a $set_defaults flag parameter on the create() method, then I think this can cover all the use cases and functionality. We can then create from data with/without defaults, and the same for new exportables. We can use this method for both.

Test for creating with $set_defaults set to false too.

Comments

damiankloip’s picture

Issue tags: +VDC

Every time.....

tim.plunkett’s picture

Status: Needs review » Needs work
+++ b/lib/Drupal/ctools/DatabaseExportableController.phpundefined
@@ -310,12 +310,17 @@ class DatabaseExportableController extends ExportableControllerBase {
+        if ($set_defaults) {
+          $data[$field] = !empty($info['default']) ? $info['default'] : NULL;
+        }
+        else {
+          $data[$field] = NULL;

I think the ternary is still fine:
$data[$field] = ($set_defaults && !empty($info['default'])) ? $info['default'] : NULL;

damiankloip’s picture

Status: Needs work » Needs review
StatusFileSize
new2.7 KB

Sure, that does make more sense.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

This looks fine now

damiankloip’s picture

Status: Reviewed & tested by the community » Fixed
merlinofchaos’s picture

Status: Fixed » Active
     foreach ($this->schema['fields'] as $field => $info) {
       // Get a default if nothing exists.
       if (!isset($data[$field])) {
-        $data[$field] = !empty($info['default']) ? $info['default'] : NULL;
+        $data[$field] = ($set_defaults && !empty($info['default'])) ? $info['default'] : NULL;
       }
     }

This sets a key to NULL if it has a default but we chose not to set defaults, but does not set the key if we neglected to give it a default. We should set all schema keys regardless of whether it has an explicit default.

  $default = NULL;
  if ($set_defaults && !empty($info['default'])) {
    $default = $info['default'];
  }

Also we seem to have lost the 'object default' I had. This existed because longtext and blob cannot have defaults in SQL but sometimes need defaults, so I created a non sql key as a workaround. We should probably retain that as well. Perhaps with a comment so that other people understand why I did that. ;)

Marking this active for this adjustment.

damienmckenna’s picture

Issue summary: View changes

The 8.x-1.x branch has been abandoned, 8.x-2.x is being rewritten from scratch, so this is no longer relevant.

Feel free to reopen if there's a project it's still appropriate for.

damienmckenna’s picture

Status: Active » Closed (won't fix)