Question: I was wondering, is it possible to have for instance a jenkins multijob that contains a "job" select input parameter ?

I want to create a multijob that : 

1 - run a job A

2 - run the selected job (for instance "Hello\_world")

3 - run job B

Answer: 
I just pass nulls. Here's my NodeJS script for loading data from file into DynamoDB, I just use ternaries to avoid empty strings.

```js
var AWS = require("aws-sdk");
var fs = require('fs');

// Make sure we got a filename on the command line.
if (process.argv.length < 3) {
  console.log('Usage: node ' + process.argv[1] + ' FILENAME');
  process.exit(1);
}

var filename = process.argv[2];

AWS.config.update({
    region: "us-west-2",
    //endpoint: "http://localhost:8000"
});

var docClient = new AWS.DynamoDB.DocumentClient();

console.log("Importing Addresses into DynamoDB. Please wait.");

var allObjs = JSON.parse(fs.readFileSync(filename, 'utf8'));
allObjs.forEach(function(obj) {
    var params = {
        TableName: "Address",
        Item: {
            "address_detail_pid":  obj.address_detail_pid,
            "flat_type":  obj.flat_type == '' ? null : obj.flat_type,
            "flat_number":  obj.flat_number == '' ? null : obj.flat_number,
            "level_type":  obj.level_type == '' ? null : obj.level_type,
            "level_number":  obj.level_number == '' ? null : obj.level_number,
            "number_first":  obj.number_first == '' ? null : obj.number_first,
            "street_name":  obj.street_name == '' ? null : obj.street_name,
            "street_type_code":  obj.street_type_code == '' ? null : obj.street_type_code,
            "locality_name":  obj.locality_name == '' ? null : obj.locality_name,
            "state_abbreviation":  obj.state_abbreviation == '' ? null : obj.state_abbreviation,
            "postcode":  obj.postcode == '' ? null : obj.postcode,
            "longitude":  obj.longitude == '' ? null : obj.longitude,
            "latitude":  obj.latitude == '' ? null : obj.latitude
        }
    };

    docClient.put(params, function(err, data) {
       if (err) {
           console.error("Unable to add obj", obj.address_detail_pid, ". Error JSON:", JSON.stringify(err, null, 2));
       } else {
           console.log("PutItem succeeded:", obj.address_detail_pid);
       }
    });
});

```
Since [DynamoDB is NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html), you can look at this in an entirely different way:

**Instead of trying to add a "null"/empty value into DynamoDB, just plan on not attempting to add the attribute itself with the "null" value in the first place...**

*"null"-check in code, instead by checking if the *attribute itself* is present [by attribute name]:*

* If not present, interpret that as "null" for the state of that variable/attribute in code
* If present, then it has a non-null value
* If trying to set an existing attribute from non-"null" to "null", just remove the attribute
* If trying to set what is ("conceptually" at the moment) a "null" value to non-"null", add the attribute [with its non-"null" value]

Note my use of quotes on "null" above - I did that on purpose to emphasize that if you use this thinking of representing null by not mapping its attribute itself, then there is no attribute that *actually* exists as "null" (no attribute that *actually* holds an *actual* "null" value).

\*Besides the benefit of capturing "null"-checking in this way being possible in itself, this strategy has an **additional benefit of saving [at least some] DynamoDB storage space, & read/write capacity units** (i.e: [on-demand pricing](https://aws.amazon.com/dynamodb/pricing/on-demand/) limits 1 write unit to 1kb & 1 read unit to 4kb): No attribute stored to represent "null" means no storage otherwise spent! I don't for a fact, but I am guessing Amazon intentionally makes AWS architecture design choices to force decisions/tradeoffs like this: Operate under constraint of things like {no null values, no empty sets}, and save resources that would otherwise be spent on them.

Once again, this is all possible because of DynamoDB's NoSQL implementation - unlike a *SQL* database, *NoSQL data can be unstructured*; and in particular, the unstructured-ness can be leveraged in this case to *include* an attribute in some documents in a given DynamoDB table and *not* other documents (in the same table). It is impossible to do the analogous same thing in a SQL database as each db row there must have *all* columns - that's what forces having to set a SQL variable/column to `null` for records where "no value" is desired (note my different formatting of `null` in this sentence ;), and not being able to just "not include the column/variable" on that row. NoSQL's version to "not include a column on some rows" is possible by just not including an attribute (which it can do because NoSQL is *unstructured* :)

\*This strategy can still be used for benefits despite the fact that [Amazon DynamoDB now supports empty values for non-key String and Binary attributes](https://aws.amazon.com/about-aws/whats-new/2020/05/amazon-dynamodb-now-supports-empty-values-for-non-key-string-and-binary-attributes-in-dynamodb-tables/) - this strategy would still at least have the exceeding benefit of saving space.

\***Note this strategy can also be used to represent an "empty set"** (since in DynamoDB sets must have at least 1 value) - *just don't map the set attribute until it is desired to be non-empty ;)*

[This strategy can be read in a [similar discussion for MongoDB](https://stackoverflow.com/questions/12403240/storing-null-vs-not-storing-the-key-at-all-in-mongodb)]