I have multiple formArrays inside a form variable. On adding vuelidate validations to these formArrays/collections, Array.push doesn't work properly.
FormArray and Form Data
data() {
return {
form: {
experience: [{
employerName: '',
department: '',
from: null,
to: null,
tillDate: false,
type: null,
noOfYears: null,
noOfMonths: null,
other: null,
}],
name: '',
email: '',
phone: null,
course: null,
Vuelidate validation rules
validations: {
form: {
experience: {
$each: {
type: {
requiredIf: requiredIf(function() {
return this.openExperience;
}),
},
other: {
requiredIf: requiredIf((obj) => obj.type === 'Other'),
},
noOfMonths: {
minValue: minValue(0),
maxValue: maxValue(11),
},
noOfYears: {
minValue: minValue(0),
},
},
},
name: {
required,
},
email: {
email,
},
phone:{
numeric
},
dateOfBirth: {
maxValue(val){
return this.$dateFns.sub(new Date(),{years: 18}) > new Date(val);
}
},
},
},
Function to add formArray
addExperience(){
this.form.experience.push({
employerName: '',
department: '',
from: null,
to: null,
tillDate: false,
type: null,
noOfYears: null,
noOfMonths: null,
other: null,
});
const length = 'experience' + (this.form.experience.length-2).toString();
document.getElementById(length).scrollIntoView();
},
I tried removing the vuelidate rules and it worked as expected. Screen Recording
I had a computed property named 'open'. In the getter for the property, I clear the entire form for a specific condition. It turns out that adding another formGroup (Array.push) to the formArray would end up invoking all the computed properties, and in turn, calling the getter for 'open' and clearing the form.
I ended up moving the code block in the computed property getter to the mounted life-cycle hook and it works fine now.
I'm having some trouble with FaunaDB Indexes. FQL is quite powerful but the docs seem to be limited (for now) to only a few examples/use cases. (Searching by String)
I have a collection of Orders, with a few fields: status, id, client, material and date.
My goal is to search/filter for orders depending on their Status, OPEN OR CLOSED (Boolean true/false).
Here is the Index I created:
CreateIndex({
name: "orders_all_by_open_asc",
unique: false,
serialized: true,
source: Collection("orders"),
terms: [{ field: ["data", "status"] }],
values: [
{ field: ["data", "unique_id"] },
{ field: ["data", "client"] },
{ field: ["data", "material"] },
{ field: ["data", "date"] }
]
}
So with this Index, I want to specify either TRUE or FALSE and get all corresponding orders, including their data (fields).
I'm having two problems:
When I pass TRUE OR FALSE using the Javascript Driver, nothing is returned :( Is it possible to search by Booleans at all, or only by String/Number?
Here is my Query (in FQL, using the Shell):
Match(Index("orders_all_by_open_asc"), true)
And unfortunately, nothing is returned. I'm probably doing this wrong.
Second (slightly unrelated) question. When I create an Index and specify a bunch of Values, it seems the data returned is in Array format, with only the values, not the Fields. An example:
[
1001,
"client1",
"concrete",
"2021-04-13T00:00:00.000Z",
],
[
1002,
"client2",
"wood",
"2021-04-13T00:00:00.000Z",
]
This format is bad for me, because my front-end expects receiving an Object with the Fields as a key and the Values as properties. Example:
data:
{
unique_id : 1001,
client : "client1",
material : "concrete",
date: "2021-04-13T00:00:00.000Z"
},
{
unique_id : 1002,
client : "client2",
material : "wood",
date: "2021-04-13T00:00:00.000Z"
},
etc..
Is there any way to get the Field as well as the Value when using Index values, or will it always return an Array (and not an object)?
Could I use a Lambda or something for this?
I do have another Query that uses Map and Lambda to good effect, and returns the entire document, including the Ref and Data fields:
Map(
Paginate(
Match(Index("orders_by_date"), date),
),
Lambda('item', Get(Var('item')))
)
This works very nicely but unfortunately, it also performs one Get request per Document returned and that seems very inefficient.
This new Index I'm wanting to build, to filter by Order Status, will be used to return hundreds of Orders, hundreds of times a day. So I'm trying to keep it as efficient as possible, but if it can only return an Array it won't be useful.
Thanks in advance!! Indexes are great but hard to grasp, so any insight will be appreciated.
You didn't show us exactly what you have done, so here's an example that shows that filtering on boolean values does work using the index you created as-is:
> CreateCollection({ name: "orders" })
{
ref: Collection("orders"),
ts: 1618350087320000,
history_days: 30,
name: 'orders'
}
> Create(Collection("orders"), { data: {
unique_id: 1,
client: "me",
material: "stone",
date: Now(),
status: true
}})
{
ref: Ref(Collection("orders"), "295794155241603584"),
ts: 1618350138800000,
data: {
unique_id: 1,
client: 'me',
material: 'stone',
date: Time("2021-04-13T21:42:18.784Z"),
status: true
}
}
> Create(Collection("orders"), { data: {
unique_id: 2,
client: "you",
material: "muslin",
date: Now(),
status: false
}})
{
ref: Ref(Collection("orders"), "295794180038328832"),
ts: 1618350162440000,
data: {
unique_id: 2,
client: 'you',
material: 'muslin',
date: Time("2021-04-13T21:42:42.437Z"),
status: false
}
}
> CreateIndex({
name: "orders_all_by_open_asc",
unique: false,
serialized: true,
source: Collection("orders"),
terms: [{ field: ["data", "status"] }],
values: [
{ field: ["data", "unique_id"] },
{ field: ["data", "client"] },
{ field: ["data", "material"] },
{ field: ["data", "date"] }
]
})
{
ref: Index("orders_all_by_open_asc"),
ts: 1618350185940000,
active: true,
serialized: true,
name: 'orders_all_by_open_asc',
unique: false,
source: Collection("orders"),
terms: [ { field: [ 'data', 'status' ] } ],
values: [
{ field: [ 'data', 'unique_id' ] },
{ field: [ 'data', 'client' ] },
{ field: [ 'data', 'material' ] },
{ field: [ 'data', 'date' ] }
],
partitions: 1
}
> Paginate(Match(Index("orders_all_by_open_asc"), true))
{ data: [ [ 1, 'me', 'stone', Time("2021-04-13T21:42:18.784Z") ] ] }
> Paginate(Match(Index("orders_all_by_open_asc"), false))
{ data: [ [ 2, 'you', 'muslin', Time("2021-04-13T21:42:42.437Z") ] ] }
It's a little more work, but you can compose whatever return format that you like:
> Map(
Paginate(Match(Index("orders_all_by_open_asc"), false)),
Lambda(
["unique_id", "client", "material", "date"],
{
unique_id: Var("unique_id"),
client: Var("client"),
material: Var("material"),
date: Var("date"),
}
)
)
{
data: [
{
unique_id: 2,
client: 'you',
material: 'muslin',
date: Time("2021-04-13T21:42:42.437Z")
}
]
}
It's still an array of results, but each result is now an object with the appropriate field names.
Not too familiar with FQL, but I am somewhat familiar with SQL languages. Essentially, database languages usually treat all of your values as strings until they don't need to anymore. Instead, your query should use the string definition that FQL is expecting. I believe it should be OPEN or CLOSED in your case. You can simply have an if statement in java to determine whether to search for "OPEN" or "CLOSED".
To answer your second question, I don't know for FQL, but if that is what is returned, then your approach with a lamda seems to be fine. Not much else you can do about it from your end other than hope that you get a different way to get entries in API form somewhere in the future. At the end of the day, an O(n) operation in this context is not too bad, and only having to return a hundred or so orders shouldn't be the most painful thing in the world.
If you are truly worried about this, you can break up the request into portions, so you return only the first 100, then when frontend wants the next set, you send the next 100. You can cache the results too to make it very fast from the front-end perspective.
Another suggestion, maybe I am wrong and failed at searching the docs, but I will post anyway just in case it's helpful.
My index was failing to return objects, example data here is the client field:
"data": {
"status": "LIVRAISON",
"open": true,
"unique_id": 1001,
"client": {
"name": "TEST1",
"contact_name": "Bob",
"email": "bob#client.com",
"phone": "555-555-5555"
Here, the client field returned as null even though it was specified in the Index.
From reading the docs, here: https://docs.fauna.com/fauna/current/api/fql/indexes?lang=javascript#value
In the Value Objects section, I was able to understand that for Objects, the Index Field must be defined as an Array, one for each Object key. Example for my data:
{ field: ['data', 'client', 'name'] },
{ field: ['data', 'client', 'contact_name'] },
{ field: ['data', 'client', 'email'] },
{ field: ['data', 'client', 'phone'] },
This was slightly confusing, because my beginner brain expected that defining the 'client' field would simply return the entire object, like so:
{ field: ['data', 'client'] },
The only part about this in the docs was this sentence: The field ["data", "address", "street"] refers to the street field contained in an address object within the document’s data object.
This is enough information, but maybe it would deserve its own section, with a longer example? Of course the simple sentence works, but with a sub-section called 'Adding Objects to Fields' or something, this would make it extra-clear.
Hoping my moments of confusion will help out. Loving FaunaDB so far, keep up the great work :)
I have a very simple collection with documents that look like this:
{
...
latestEdit: Time(...),
lastPublished: Time(...)
}
I would like to query all documents that have a latestEdit time that's after lastPublished time.
I find FQL to be very different to SQL and I'm finding the transition quite hard.
Any help much appreciated.
Fauna's FQL is not declarative, so you have to construct the appropriate indexes and queries to help you solve problems like this.
Fauna indexes have a feature called "bindings", which allow you to provide a user-defined function that can compute a value based on document values. The binding lets us index the computed value by itself (rather than having to index on latestEdit or lastPublished). Here's what that might look like:
CreateIndex({
name: "edit_after_published",
source: {
collection: Collection("test"),
fields: {
needsPublish: Query(
Lambda(
"doc",
Let(
{
latestEdit: Select(["data", "latestEdit"], Var("doc")),
lastPublished: Select(["data", "lastPublished"], Var("doc")),
},
If(
GT(Var("latestEdit"), Var("lastPublished")),
true,
false
)
)
)
)
}
},
terms: [ { binding: "needsPublish" } ]
})
You can see that we define a binding called needsPublish. The binding uses Let to define named values for the two document fields that we want to compare, and then the If statement checks to see if the latestEdit value is greather than lastPublished value: when it is we return true, otherwise we return false. Then, the binding is used in the index's terms definition, which defines the fields that we want to be able to search on.
I created sample documents in a collection called test, like so:
> Create(Collection("test"), { data: { name: "first", latestEdit: Now(), lastPublished: TimeSubtract(Now(), 1, "day") }})
{
ref: Ref(Collection("test"), "306026106743423488"),
ts: 1628108088190000,
data: {
name: 'first',
latestEdit: Time("2021-08-04T20:14:48.121Z"),
lastPublished: Time("2021-08-03T20:14:48.121Z")
}
}
> Create(Collection("test"), { data: { name: "second", lastPublished: Now(), latestEdit: TimeSubtract(Now(), 1, "day") }})
{
ref: Ref(Collection("test"), "306026150784664064"),
ts: 1628108130150000,
data: {
name: 'second',
lastPublished: Time("2021-08-04T20:15:30.148Z"),
latestEdit: Time("2021-08-03T20:15:30.148Z")
}
}
The first document subtracts one day from lastPublished and the second document subtracts one day from latestEdit, to test both conditions of the binding.
Then we can query for all documents where needsPublish results in true:
> Map(Paginate(Match(Index("edit_after_published"), true)), Lambda("X", Get(Var("X"))))
{
data: [
{
ref: Ref(Collection("test"), "306026106743423488"),
ts: 1628108088190000,
data: {
name: 'first',
latestEdit: Time("2021-08-04T20:14:48.121Z"),
lastPublished: Time("2021-08-03T20:14:48.121Z")
}
}
]
}
And we can also query for all documents where needsPublish is false:
> Map(Paginate(Match(Index("edit_after_published"), false)), Lambda("X", Get(Var("X"))))
{
data: [
{
ref: Ref(Collection("test"), "306026150784664064"),
ts: 1628108130150000,
data: {
name: 'second',
lastPublished: Time("2021-08-04T20:15:30.148Z"),
latestEdit: Time("2021-08-03T20:15:30.148Z")
}
}
]
}
I'm having an issue running a test on a large complicated Vuetify component with many smaller components, the important parts:
<cat-form
:dogs="dogs"
:cats="cats"
>
</cat-form>
.....
props: [
'availablecats',
'avaliabledogs'
],
.....
computed: {
advertisers() {
var dogs = JSON.parse(this.avaliabledogs)
return dogs
},
cats() {
var cats = JSON.parse(this.availablecats)
return cats
},
And then the test using Vue-utils:
describe('CreateCat', function () {
let props = {
avaliablecats : [{
name: 'cat1',
age: 2
},
{
name: 'cat2',
age: 4
}],
avaliabledogs : [{
name: 'dog1',
age: 3
},
{
name: 'dog2',
age: 8
}],
}
beforeEach(() => {
wrapper = mount(CreateCat, {
propsData: props,
computed: {
dogs() {
return props.avaliabledogs
},
cats() {
return props.avaliablecats
},
}
});
});
test('true is true', () => {
expect(true).toEqual(true)
})
});
This is the error I receive:
SyntaxError: Unexpected token o in JSON at position 1
at JSON.parse (<anonymous>)
143 |
144 | cats() {
> 145 | var cats= JSON.parse(this.avaliablecats)
| ^
146 | return cats
147 | },
Firstly, I thought if I mocked the props data, then the computed method could be calculated and wouldn't consider this.avaliabledogs and this.avaliblecats as undefined. But that didn't work.
I next tried to mock the computed methods then the function wouldn't be called at all. But I'm still receiving exactly the same error.
I've also tried the below methods as an alternate way to set computed methods and props after mounting the wrapper rather than including them when I first mount the component.
wrapper.setProps({
avaliablecats : [{
name: 'cat1',
age: 2
},
{
name: 'cat2',
age: 4
}],
avaliabledogs : [{
name: 'dog1',
age: 3
},
{
name: 'dog2',
age: 8
}],
})
wrapper.setComputed({
cats: [{
name: 'cat1',
age: 2
},
{
name: 'cat2',
age: 4
}],
dogs: [{
name: 'dog1',
age: 3
},
{
name: 'dog2',
age: 8
}],
})
I then tried stubbing the entire 'cat-form' component that used dogs and cats. Again, still getting the error.
wrapper = mount(CreateCat, {
stubs: {
CatForm: true,
},
I'm at a bit of a loss now - I feel like I've used the right syntax but I am getting confused why the methods in the computed property are still being called when i've mocked the computed function?
Any help would be very much appreciated!
JSON.parse(this.avaliabledogs) implies that avaliabledogs prop is valid JSON string. While it's an array of objects in this test, converting it to a string results in something like:
[object Object],[object Object]
This is what infamous SyntaxError: Unexpected token o in JSON error indicates.
In this case there's no need to mock computed properties (can be done like shown here) because they are too small to be considered separate units that need to be isolated; this can be achieved with properly mocked props:
let props = {
avaliablecats : JSON.stringify([{
name: 'cat1',
age: 2
},
{
name: 'cat2',
age: 4
}]),
avaliabledogs : JSON.stringify([{
name: 'dog1',
age: 3
},
{
name: 'dog2',
age: 8
}]),
}
I want to easily query such results:
[{
name: 'john_doe',
info: {
age: 24,
notes: 'custom text',
phoneNumbers: {
home: 112345678,
work: 1234567,
},
},
}, {...}, {...}...]
... by such query:
contacts.filtered("info.age = 24 AND info.notes CONTAINS 'custom'");
How should i create such schema? docs are very confusing about data types and nested properties:
https://realm.io/docs/react-native/0.14.0/api/Realm.html#~PropertyType
https://realm.io/docs/react-native/latest/#nested-objects
I do not need to retrieve any parts of this data separately - only complete object with all nested objects at once.
You could put all fields into a single object:
var ContactSchema = {
name: 'Contact',
properties: {
name: 'string',
age: 'int',
notes: 'string',
homePhone: 'string',
workPhone: 'string'
}
};
Alternatively you could create child objects for info and phoneNumbers but if you are not sharing this data across multiple contacts then this probably isn't needed.