You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Can we make the generated queries more verbose? In the way that when provided a property to the update of where param/object that is not part of the target subject (field on entity), we get some error/info? And if so, should we make it an hard fail of just a notice?
Example;
// example entityconstentity={name: T.string(),birthDate: T.date().optional(),};awaitqueries.entityUpdate(sql,{birthPlace: "No place like 127.0.0.1"},{ id });// expected result:INFO{type: "query",msg: "No field 'birthPlace' on 'entity', available fields: 'name', 'birthDate'"}
Additions; same for non fields, but where clause condition 'fields'. Like array fields, number fields. {field}In, {field}NotIn. For example; when providing the where object with keysIn instead of keyIn (for field name; key). It should let the user know.
The text was updated successfully, but these errors were encountered:
We don't have a logger there, so we can only do a hard fail
We need to dump all possible keys, in the partials: entityWhere & entityUpdateSet, entityInsertvalues and then loop over the keys, checking if they exists in the known set.
If we use a Set for the last part, we can keep it O(n) where N is the amount of keys in the passed in objects.
We can easily reuse the generated Sets by generating them at the top of the query-partials file, so at least we don't allocate them every call.
For the error part, something like the following:
new AppError("query.{entity}.{where|update|insert}Fields", 500, { unknownKey: "xxx", knownKeys: xxxFieldSet });
This works by dumping the possible keys, and looping over the input objects. It is guarded by an `isStaging()` check, so shouldn't be too much of a performance hit.
Closes#466
This works by dumping the possible keys, and looping over the input objects. It is guarded by an `isStaging()` check, so shouldn't be too much of a performance hit.
Closes#466
Can we make the generated queries more verbose? In the way that when provided a property to the
update
ofwhere
param/object that is not part of the target subject (field on entity), we get some error/info? And if so, should we make it an hard fail of just a notice?Example;
Additions; same for non fields, but where clause condition 'fields'. Like array fields, number fields.
{field}In
,{field}NotIn
. For example; when providing the where object withkeysIn
instead ofkeyIn
(for field name;key
). It should let the user know.The text was updated successfully, but these errors were encountered: