WARNING: value functions are DEPRECATED and will be removed soon.

[gparonitti]

Hi,
Why are you going to remove value functions?
The perfect use case is for dynamical and automatic sharding of an index via partition key.
For example if I want to have a partition with all the user in updating order (imagine millions of users) i have to shard the data for example by year and week:

const getYear = (ts = Date.now()) => new Date(ts).getFullYear()

const getWeek = (ts = Date.now()) => {
  const aDayInMs = 24 * 60 ** 2 * 1000
  const currentDay = new Date(ts)
  const oneJan = new Date(currentDay.getFullYear(), 0, 1)
  const daysN = Math.ceil((Number(currentDay) - Number(oneJan)) / aDayInMs)
  return Math.ceil(daysN / 7)
}
const createUserTimeStampsPK = key => (_, properties) =>
  properties[key] &&
  `USERS#BY#UPDATE#${getYear(properties[key])}-${getWeek(properties[key])}`

const MainTableSchema = {
  version: '1.1.0',
  format: 'onetable:1.1.0',
  indexes: {
    primary: { hash: 'pk', sort: 'sk' },
    GS1: { hash: 'gs1pk', sort: 'gs1sk' },
    GS2: { hash: 'gs2pk', sort: 'gs2sk' },
    ...
    GS11: { hash: 'gs11pk', sort: 'gs11sk' },
    GS12: { hash: 'gs12pk', sort: 'gs12sk' }
  },
  models: {
   User: {
      // Attributes indexed by primary key
      pk: { type: String, value: 'USERNAME#${username}' },
      sk: { type: String, value: 'USERNAME#${username}' },

      // Attributes indexed by GSI
      gs1pk: { type: String, value: 'USER#EMAIL#${email}' },
      gs1sk: { type: String, value: 'USER#EMAIL#${email}' },
      gs2pk: { type: String, value: 'USER#ID#${userId}' },
      gs2sk: { type: String, value: 'USER#ID#${userId}' },
      gs12pk: { type: String, value: createUserTimeStampsPK('updatedAt') },
      gs12sk: { type: String, value: 'UPDATED#${updatedAt}' },
      email: { type: String, required, unique: true },
      updatedAt: { type: Date },
      userId: { type: String, required },
      username: { type: String, required }
  }
},
  params: {
    updatedField: 'updatedAt',
    createdField: 'createdAt',
    timestamps: false,
    typeField: '_model',
    isoDates: false
  }

The alternative is to have to remember every model partition key and save or update the PKs every time I need a different shard (now I have 10 models sparse in 12 indexes in one table). IMHO value functions are very valuable for reducing code complexity and footprint, and shouldn't be removed 😅.

Cheers.

[mobsense]

We are removing schema literal value functions and directing users to define these via the table constructor. There should be no loss of functionality. It is just relocated to the Table constructor params where you can define your value template functions via the params {value: Function}.

The reason we are doing this is to support schemas being persisted to storage for tooling to assist in schema creation and management. For this, they must be static literal with no-embedded functions. Adding embedded functions blocks this functionality.

See the table constructor doc:

Value Template Function

Value templates are defined in the schema for model fields. These are typically literal strings with property variable references. In some use cases, more complex logic for a value template requires a function to calculate the property value at runtime. The Table constructor params.value function provides a centralized place to evaluate value templates. It will be invoked for fields that define their value template to be true.

The value template function is called with the signature:

str = value(model, fieldName, properties, params)

The value template should return a string to be used for the given fieldName. The properties and params are corresponding arguments given to the API.

[mobsense]

I can't see how that can work. I just tested in the current code and functions are not called for default properties in schema fields. Nor is there any code that I can identify that would do that.

Can you share your code for specifying functions in schema. What version are you using?

[dmeehan1968]

I'm using OneTable 2.5.1.

Here is a typical attribute from a model (this is working code):

serverTime: { type: Date, default: () => new Date(), required: true },

Here is the relevant support in the source:

dynamodb-onetable/src/Model.js

Lines 1091 to 1093 in cd0186d

	if (typeof field.default == 'function') {
	// DEPRECATED
	value = field.default(this, field.name, properties)

Note that this suggests deprecation, and seemingly for the same reason as for value functions (to allow schemas to be literal) but @mobsense suggested below there is currently not an alternative for default functions.

[mobsense]

That is not doing what you think it is doing.

That legacy code is only applied after the database operation. So your default function is not being called before writing to the database.

[dmeehan1968]

@mobsense Hmmm, curious to understand how my table is being populated with those default values if that's the case. Also, I'm using batch writes in some instances, and when I call create() and inspect the returned value (after await) and before the batchWrite() call, the values are populated with the results of the default functions. As in the example, most fields with defaults are marked as 'required', so how does this pass validation?

If you are saying that its not possible to use default functions to supply values not specified in the create() properties, then how should I be populating these values?

As it stands, the documenations for 'Value and Default Functions' at the bottom of the Model Attributes page clearly states that both model and value functions are supported, with the caveat that is blocks use of tools such as SenseDeep due to the non-literal nature. What is the way forward?

[mobsense]

Thanks for the note on the doc. We'll remove that text.

If you need computed properties, apply them directly via the API. If literal, then apply via the schema. We made this tradeoff in functionality to get a literal schema. Sorry, but we can't have everything.

The returned values when using batch and transactions from the API calls themselves are just the values you provide. So the legacy default function will be run on the returned values, but not on the data applied to the database. There may be somethings special happening with batches -- not sure off the top of my head. But we intend to remove that deprecated code regardless in 2.6.

[mobsense]

There isn't a Table params.default callback function in the code currently.