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
Simple columns like fooBar: {path: 'foo.bar'} could work in a following way:
import{IS_NULL,IS_NOT_NULL}from'strato-db'// to search for equalityawaitmodel.search({fooBar: 'BAZ'})// to search for null foo.barawaitmodel.search({fooBar: IS_NOT_NULL})// to search for non-null foo.barawaitmodel.search({fooBar: IS_NULL})
If you implement your own where as a string, then using those symbols would throw.
If you implement your own where as a function, then you are responsible for handling those symbols by yourself.
Thanks to that:
you have consistent naming in all the projects (with custom columns for null/not null you have a lot of naming conventions to choose => easy to lose consistency)
code is more DRY
Having such an option should also reduce the need of using where as a function, which is very welcome (where as a function has no easy option to prepare statements)
The text was updated successfully, but these errors were encountered:
Simple columns like
fooBar: {path: 'foo.bar'}
could work in a following way:If you implement your own
where
as a string, then using those symbols would throw.If you implement your own
where
as a function, then you are responsible for handling those symbols by yourself.Thanks to that:
Having such an option should also reduce the need of using
where
as a function, which is very welcome (where
as a function has no easy option to prepare statements)The text was updated successfully, but these errors were encountered: