Allow NodeJS driver to apply automatic type conversion in query parameters

[josiahjohnston]

The NodeJS cassandra driver offers automatic & safe type conversion for prepared queries. This is great for simpler code that doesn't have to convert strings to UUID types, dates, etc. Ex:

cql_client.execute(
    'SELECT * FROM keyspace.sample_table where "id" = ?;', 
    [ 'd8160520-5f6d-11eb-af42-0a1f69b793a6'], 
    { prepare : true }
).then(dat => {console.log(`results obtained: ${dat.length}`); }
).catch(error => console.log(`got error ${error}`));

Express Cassandra prepares all queries by default, so I expected this feature to be available. But when I try to query with a string UUID instead of a UUID type, I get an error because string isn't a UUID type. The error is thrown by lib/utils/parser.js get_db_value_expression(). This forces me to write queries like models.datatypes.Uuid.fromString(id) instead of id.

Is there some way to bypass that type checking? If not, would you consider supporting that feature?

[masumsoft]

@josiahjohnston thanks for the report, I've just prepared a fix for it. You'll now be able to disable automated type checks for a specific field by setting a model schema rule for that field. Details available in validator doc. Hope to release it soon with the next version.

[josiahjohnston]

Thank you so much for the prompt reply! Would it be possible to apply this at the driver level instead of each field? In or use cases, we never want to override the prepared statements flag, and would appreciate the performance benefit of having a single robust layer apply type conversions. With your proposed changes, we would have to edit most of the fields in our models rather than applying a blanket config change.

[masumsoft]

Good point. We have existing users of the library who rely on the data type validation of express-cassandra. Hence adding a common configuration to disable the built in type checks all together should solve the problem without impacting other users of the library. Hope it'll solve the problem.

[josiahjohnston]

Yes, that would be perfect. I tried to read the code to understand how to best accomplish it, but don't understand arch well enough to see the cleanest strategy.

Makes sense that some users relied on that legacy behavior, and changes could break things for them.