Form data is not saving fields after updating them

Ask the community
,
1

Hi all. I have some fields in my form that can be duplicate by checking a checkbox. If I enter data by the keyboard it persists provided data. But if I check the box, it updates the input boxes that could be duplicate on the screen but not the collections’s fields, after submitting. In addition, after I have defined a specific field as a “MAIN FIELD”, I expected to get just one record to that content but it is allowing more than one record with the same value. I noticed that there is a Created Date automatic field that is a Main Field to. Can it being resulting in a composed key, allowing my main field to be NOT unique? (any fields that can be duplicate is a key in the collection, I mean, they are not MAIN FIELDS) Thanks for advance.

Follow the code:

// For full API documentation, including code examples, visit Velo API Reference - Wix.com

$w.onReady( function () {

});

export function checkbox1_change(event, $w) {
if ($w(“#checkbox1”).checked === true ){
$w(“#input5”).value = $w(“#input4”).value;
$w(“#input15”).value = $w(“#input14”).value;
$w(“#input18”).value = $w(“#input17”).value;
$w(“#dropdown3”).value = $w(“#dropdown2”).value
$w(“#input6”).value = $w(“#input1”).value;
} else {
$w(“#input5”).value =“”;
$w(“#input15”).value = “”;
$w(“#input18”).value = “”;
$w(“#dropdown3”).value = “”;
$w(“#input6”).value = “” ;
}

}

export function checkbox2_change(event, $w) {
if ($w(“#checkbox2”).checked === true ){
$w(“#input9”).value = $w(“#input7”).value;
} else {
$w(“#input9”).value =“”;
}

}

2

Alosio, Wix is pretty clear concerning the behaviour of setting a value: onItemsChanged is not triggered by this, so these values will NOT be written to the collection. In order to do so, you will have to call setItemsValue. Have a look at the API documentation.
Also, Wix database does not know a NODUPS option.

3

Hi Giri Zano. Thanks for your help. I’m trying to find the right API to correct my error. I am a newbie on WIX so I ask you for your understanding. About NODUPS option, I thought a reference field was what is described on CMS: About Reference Fields in Database Collections | Help Center | Wix.com
(Advantages of Using Reference Fields). How do I avoid duplicating records in my collections? Thanks again.

4

OK, API doc is here: wix-dataset - Velo API Reference - Wix.com

A “Reference field” is Wix Code is a Foreign Key that references the only Primary Key available in the referenced collection: _id (you know, the dg48gjdu38fjks-keys). Since the relation can be a 1-to-many, the “many”-part can never be NODUPS. But now it gets hairy: in the Master collection Wix lets you specify a “Primary Key”. This is a very wrong and confusing term, because it is not. It should be called the “non-unique display field for Content Manager only”, but I agree, that is a bit long.

Let´s work with an example. Let´s say this is the table schema for the Main Collection:
Coupon Name (String), Coupon Code (string/Primary Key), Valid_thru (date), _id
with a row filled like this
10 % Discount, 12345, 01/01/2019, a1b2c3d4

Now we define a coupons_used collection, which writes a row to a separate collection every time a coupon is used, like this

Date_used, Coupon_Reference(to Coupon Code), _id
To your surprise, you will see that it will be filled like this (underneath, at raw database level):
10/10/2018, a1b2c3d4, z1y2t3u4

You would expect that the reference field would be 12345, but it is not: as I said above, the reference field is a Foreign Key to the only real primary key that the above table has, the _id.

But, Wix must have thought: well, in the Content Manager (you know, the database grid), this look kind of non-descriptive, so let´s DISPLAY something else. But what? Well, let the developer indicate which field from the Main collection he wants displayed (Coupon Code), and then, instead of displaying a1b2c3d4 we will display 12345!!
But, this ONLY works in the Content Manager. If you retrieve the Detail Collection in code, or you write to it, YOU DO THIS BY WRITING THE _ID OF THE MAIN COLLECTION AND NOT THE COUPON CODE!!

And Wix then thought: let´s give this “non-unique display field for Content Manager only” a short, catchy name: Primary Key! And that was, in my opinion, a mistake, for a Primary Key already exists (the _id), which is, like every normal Primary Key, NODUPS, but this new Primary Key is not at all a Primary Key, it´s… a non-unique display field for Content Manager only.

So how do you prevent duplicate “primary keys” (like the coupon code). Answer: you have to check yourself, with code, before you write to the Main collection, if this “Primary Key” exists or not.

Yisrael lately wrote an article on how to do this : https://www.wix.com/code/home/forum/wix-tips-and-updates/example-no-database-duplicates

Hope this helps.

5

OK, API doc is here: wix-dataset - Velo API Reference - Wix.com

A “Reference field” is Wix Code is a Foreign Key that references the only Primary Key available in the referenced collection: _id (you know, the dg48gjdu38fjks-keys). Since the relation can be a 1-to-many, the “many”-part can never be NODUPS. But now it gets hairy: in the Master collection Wix lets you specify a “Primary Key”. This is a very wrong and confusing term, because it is not. It should be called the “non-unique display field for Content Manager only”, but I agree, that is a bit long.

Let´s work with an example. Let´s say this is the table schema for the Main Collection:
Coupon Name (String), Coupon Code (string/Primary Key), Valid_thru (date), _id
with a row filled like this
10 % Discount, 12345, 01/01/2019, a1b2c3d4

Now we define a coupons_used collection, which writes a row to a separate collection every time a coupon is used, like this

Date_used, Coupon_Reference(to Coupon Code), _id
To your surprise, you will see that it will be filled like this (underneath, at raw database level):
10/10/2018, a1b2c3d4, z1y2t3u4

You would expect that the reference field would be 12345, but it is not: as I said above, the reference field is a Foreign Key to the only real primary key that the above table has, the _id.

But, Wix must have thought: well, in the Content Manager (you know, the database grid), this look kind of non-descriptive, so let´s DISPLAY something else. But what? Well, let the developer indicate which field from the Main collection he wants displayed (Coupon Code), and then, instead of displaying a1b2c3d4 we will display 12345!!
But, this ONLY works in the Content Manager. If you retrieve the Detail Collection in code, or you write to it, YOU DO THIS BY WRITING THE _ID OF THE MAIN COLLECTION AND NOT THE COUPON CODE!!

And Wix then thought: let´s give this “non-unique display field for Content Manager only” a short, catchy name: Primary Key! And that was, in my opinion, a mistake, for a Primary Key already exists (the _id), which is, like every normal Primary Key, NODUPS, but this new Primary Key is not at all a Primary Key, it´s… a non-unique display field for Content Manager only.

So how do you prevent duplicate “primary keys” (like the coupon code). Answer: you have to check yourself, with code, before you write to the Main collection, if this “Primary Key” exists or not.

Yisrael lately wrote an article on how to do this : https://www.wix.com/code/home/forum/wix-tips-and-updates/example-no-database-duplicates

Hope this helps.

6

Very well explained, Giri.
Unlike other databases, as you said, naming such a field as Primary Key does not have the same connotation. That’s why I was confused. i will check out about the API and Yisrael article. Thanks a lot.