Closed urugator closed 1 year ago
I tend to agree with that. there would be 2 options concerning metadata :
metaAsArray
option for mysql2 compatibility : like const [rows, meta] = conn.query('...');
metaEnumerable
if needed for compatibility. example : with current implementation:
const res = await connection.query('select * from animals');
console.log(res):
// [
// { id: 1, name: 'sea lions' },
// { id: 2, name: 'bird' },
// meta: [ ... ]
// ]
A better solution would be to still have meta property, but nonenumerable:
const res = await connection.query('select * from animals');
console.log(res):
// res : [
// { id: 1, name: 'sea lions' },
// { id: 2, name: 'bird' }
// ]
const meta = res.meta;
// meta: [ ... ]
Didn't know about metaAsArray
, seems not to be documented (on github) or part of type defs.
I would vote for metaEnumerable
even though it means a new option.
Plus a note in docs that false
will be default in next major (?).
exactly my point.
Documentation is always a work in progress. thanks for pointing that out. I've just added it in develop branch: https://github.com/mariadb-corporation/mariadb-connector-nodejs/blob/develop/documentation/promise-api.md#metaasarray
@rusher I think the docs could be wrong, or I missunderstood it.
current docs say:
const [rows, meta] = await connection.query({ metaAsArray: true, sql: 'select * from animals' });
// rows = [
// [ 1, 'sea lions' ],
// [ 2, 'bird' ],
// ]
// meta = [...]
shouldn't it be like:
const [rows, meta] = await connection.query({ metaAsArray: true, sql: 'select * from animals' });
// rows = [
// {'id': 1, 'name': 'sea lions' },
// {'id': 2, 'name': 'bird' },
// ]
// meta = [...]
because in my test the "root" result object now is correctly sepperated in an array, but the data is still json (which i love). When reading the docs I thought its all arrays now.
@MR4online Yes, looks like a copy-paste mistake (copied from rowsAsArray)
yes, that is now corrected ( in commit https://github.com/mariadb-corporation/mariadb-connector-nodejs/commit/ba70356ae9485120120b57843f9157ac83145f04 )
precision, metaEnumerable is not handled in batch command, this will be corrected in 3.1.1
closing since 3.1.1 is released
The result set's meta info is rarely needed, therefore I appreciate it's exposed to the user in a way that doesn't complicate the API for majority of use cases. Likewise I think it shouldn't make day-to-day debugging and testing more complicated. As it is now: 1) It clutters console output with a lot of unneeded information. 2) It fails test assertions against plain arrays (using
jest
)As a result a user is forced to create copy or redefine the prop every time, which is inconvinient and may have some perf implications.
For these reasons, I propose to make
meta
property non-enumerable, solving both of the stated problems.