JOI 10 is used to validate calls against an API. I now want to sanitize many (but not all) of the strings that are contained in the JSONs before validating them, namely filter out certain characters. I know that this would be an easy task with a recent JOI version as there's the custom() method that I could use. Unfortunately updating JOI is not an option and so I am currently looking for an elegant way to solve this, preferably using the JOI schemas.
I found that there is the extend() function which allows me to define custom types/validations. However, I am not entirely sure how to use it and where to put the code. Also, I am not sure if it's suited to alter the string at all. Can I use extend() to achieve this? If not, is there another way to do this within JOI?
OK, it's actually pretty easy.
const customJOI = JOI.extend({
name: "sanitizedString",
base: JOI.string(),
pre(value: string, state: any, options: any) {
return value.replace(/yourregex/, "");
}
});
and just use customJOI instead of JOI where the sanitization is needed with .sanitizedString() instead of .string().
Related
In kitchen.yml, I would like to have an expression in the attributes: part. However it seems it is just a static file with literal values.
Is it somehow possible to have the values in attributes: evaluated?
The reason for that need is that I have some node.defaults in defaults.rb, and some of them are URLs at the same host, say, http:foo.org/service. And in the kitchen.yml I want to parametrize the host. So I would have:
...
attributes: { serviceX_baseURL: "http://bar.org/service" }
I want the override to happen with kitchen_*.yml override and not attributes/*.rb (that would be easier) because the override happens later in the process, after the main kitchen.yml file is already generated.
Any practical solutions for that are welcome.
You can use Erb formatting in the .kitchen.yml for some very simplistic templating, but you didn't really give a concrete example. Chances are you should not do this, generally parameterizing both the code and tests on the same input means the tests are brittle or not testing what you think they are.
In immutable.js what is the equivalent of an empty object?
My code is:
let iState = fromJS(state)
iState = iState.setIn(['ui', 'drafts'], {})
return iState.toJS()
But I think I should not use {} when using setIn. Please advise what I should use.
The best 'empty' data structure to use will depend on your use case (and I highly recommend looking at the other data structures and use their advantages) but for the most common interface/expected behavior and structure - Record will be the closest analog. That said, I also recommend looking into the Map data structure as it has a bit more functionality baked in than Record that you may find you need.
I am using django with postgres, and have a bunch of JSON fields (some of them quite large and detailed) within my model. I'm in the process of switching from char based ones to jsonb fields, which allows me to filter on a key within the field, and I'm wondering if there is any way to get the equivalent benefit out of a call to the query set values method.
Example:
What I would like to do, given a Car model with options JSONField, is something like
qset = Car.objects.filter(options__interior__color='red')
vals = qset.values('options__interior__material')
Please excuse the lame toy problem, but hopefully it gets the idea across. Here the filter call does exactly what I want, but the call to values does not seem to be aware of the special nature of the JSON field. I get an error because values can't find the field called "interior" to join on. Is there some other syntax or option that I am missing that will make this work?
Seems like a pretty obvious extension to the existing functionality, but I have so far failed to find any reference to something similar in the docs or through stack overflow or google searches.
Edit - a workaround:
After playing around, looks like this could be fudged by inserting the following in between the two lines of code above:
qset=qset.annotate(options__interior__material=RawSQL("SELECT options->'interior'->'material'",()))
I say "fudged" because it seems like an abuse of notation and would require special treatment for integer indices.
Still hoping for a better answer.
I can suggest a bit cleaner way with using:
django's Func
https://docs.djangoproject.com/en/2.0/ref/models/expressions/#func-expressions
and postgres function jsonb_extract_path_text https://www.postgresql.org/docs/9.5/static/functions-json.html
from django.db.models import F, Func, CharField, Value
Car.objects.all().annotate(options__interior__material =
Func(
F('options'),
Value('interior'),
Value('material'),
function='jsonb_extract_path_text'
),
)
Perhaps a better solution (for Django >= 1.11) is to use something like this:
from django.contrib.postgres.fields.jsonb import KeyTextTransform
Car.objects.filter(options__interior__color='red').annotate(
interior_material=KeyTextTransform('material', KeyTextTransform('interior', 'options'))
).values('interior_material')
Note that you can nest KeyTextTransform expressions to pull out the value(s) you need.
Car.objects.extra(select={'interior_material': "options#>'{interior, material}'"})
.filter(options__interior__color='red')
.values('interior_material')
You can utilize .extra() and add postgres jsonb operators
Postgres jsonb operators: https://www.postgresql.org/docs/9.5/static/functions-json.html#FUNCTIONS-JSON-OP-TABLE
I've a function which is called from different components, .cfms or remotely. It returns the results of a query.
Sometimes the response from this function is manually inspected - a person may want to see the ID of a specific record so they can use it elsewhere.
The provided return formats, being wddx, json, plain all aren't very easily readable for a layman.
I'd love to be able to create a new return format: dump, where the result first writeDumped and then returned to the caller.
I know there'd be more complicated ways of solving this, like writing a function dump, and calling that like a proxy by providing the component, function and parameters so it can call that function and return the results.
However I don't think it's worth going that far. I figured it'd be great if I could just write a new return format, because that's just... intuitive and nice, and I may also be able to use that technique to solve different problems or improve various workflows.
Is there a way to create custom function returnFormats in ColdFusion 10 or 11?
(From comments)
AFAIK, you cannot add a custom returntype to a cffunction, but take a look at OnCFCRequest. Might be able to use it to build something more generic that responds differently whenever a custom URL parameter is passed, ie url.returnformat=yourType. Same net effect as dumping and/or manipulating the result manually, just a little more automated.
From the comments, the return type of the function is query. That being the case, there is simply no need for a custom return format. If you want to dump the query results, do so.
queryVar = objectName.nameOfFunction(arguments);
writeDump (queryVar);
I'm learning Backbone.js as I feel it will come handy for my projects.
I'm running thru different tutorials and I cant's find the difference and best declaration for a class like:
Person = Backbone.Model.extend({
defaults: {
name: 'Andy',
age: 25,
occupation: 'Whatever...'
}
});
Is it better to initialize a Class this way:
var me = new Person({name: 'Andy'});
or
var me = new Person({'name': 'Andy'});
Why should I use single quotes to set a variable? It takes more time, but what's best? What's right and why?
I'm not sure if is only a JSON matter or if is a backbone matter as actually this is a matter of initialization and use of curly brackets.
In case I use .set(var, value) and the variable has no quotes backbone throws an error as is looking for a variable.
I tried looking in Backbone.js website and JSON website but can't find an answer to this.
If we are being pedantic, then valid JSON requires the single-quotes for all keys. JSLint, for example, will reject JSON without the quotes.
But in Javascript they are not needed, and most people leave them out (as you noted, it's more concise). That is, unless you have reserved characters in the name like -, etc. So for example, { name: 'Andy' } is fine, but { first-name: 'Andy' } will cause the parser to balk.