Request For : 🦴 Database Schema Function

[chris-derrell]

Hi Corvid Team,

Making a big request for a database schema function on the Corvid wix-data API.

Usage

wixData.schema(‘collectionName’) : returns DatabaseSchemaObject (not a promise!)

DatabaseSchemaObject :
{
    fieldName:'First Name',
    fieldId:'title'
    fieldType:'text',
    dataType: String,
    position:0,
    isReference:true,
    isDeleted:false,
    isReadOnly:false
}

Field Type and Data Type would be based on the table found here - wix-data - Velo API Reference - Wix.com

Use Cases

I’ve already had to make a wonky version of this schema function to create a dynamic repeater. It automatically adds and removes fields from a dynamically created form based on the fields in the database that are available. That way the client could add, change and update the database, and the form information automatically changes too.

It can also be helpful for other websites needing to know how to format data for the API. Could be in the response of an OPTIONS/GET request from sites sending over data.

Can we make this happen?

@Giri Zano @Yisrael (Wix) @givemeawhisky @Quentin Plomteux @Salman A #

#wixdata #schema #database

[givemeawhisky]

Just note that out of that list it is only Yisrael who actually works for Wix, all the rest of us are Forum Ninjas who do this in our own free time.

Yisrael is away currently, so you won’t get a reply back from him for the time being, however hopefully somebody else from Wix might pop up and mention something.

With regards to this request, then note that you can already do schema on static pages to a degree,
https://support.wix.com/en/article/adding-schemaorg-markup
Note:
You can add Schema.org to static pages of your site. It is not possible to apply these settings to Wix Code dynamic pages or business solution pages (e.g. pages from Hotels, Restaurants, Bookings, etc.).

So well done for making a workaround for the time being, even if it is a bit of a wonky version!

However, as it is only available for static pages for now, then I don’t think that it will be made ready for use with datasets and dynamic pages as well for some time. (Although here I am hoping that somebody from Wix will come and correct me now. )

Assuming you have already seen these pages but worth listing them below so that you can vote again or check them if not.
https://support.wix.com/en/article/request-adding-multiple-structured-data-schema-items-to-your-page
https://support.wix.com/en/article/request-adding-recommended-fields-to-your-product-pages-markup-schema
https://support.wix.com/en/article/request-customizing-your-product-pages-markup-schema-structured-data
https://support.wix.com/en/article/google-data-studio-table-schema
https://support.wix.com/en/article/adding-structured-data-to-your-site
https://support.wix.com/en/article/adding-schemaorg-markup
https://www.wixcommunity.org/post/structured-data-user-guide

[chris-derrell]

Definitely noted, I linked you guys because I see you as Corvid movers and shakers who were the most likely to have been driven by the same need for a solution, and I believe you will push it if it makes sense. Didn’t even realize Yisrael worked for Wix .

I have seen some of those links, but as you said it lacks the dynamic page support. Also, it should be accessible from the built-in API.

It’s something I’m hoping will be low hanging fruit, since you can actually currently export the schema of a collection using the Collection Manager

[giri-zano]

Yes, that´s a start. But to do forms and communication well, and in a way that it should not take forever to build 30 forms for a large project, we need also:

1. being able to write DB-schema
2. being able to write forms on the fly (maybe as a component, with 90% generated or standardised code) .

If we had both, we could make forms a lot less time consuming. I would create a repository in a Wix Db with enough info to:

1. generate a collection (with refs, datatypes, etc)
2. generate a form (with form elements, max-min vals, mandatory, regex, etc inc x,y, coords) inluding all framework code to Create,Read, Update and Delete) with backend calls (so no Datasets).

Oh man, if only.

P.S: I have been thinking about using a repeater with form elements too. How did you solve these 2 problems:

1. you cannot create an input element on a repeater, it must already be there. So on every “row”, you will need to put a textbox, a checkbox, an uploadable image, a calendar, a dropdown, etc. How do you horizontally collapse the ones you do not need
2. datepicker doesn´t fit in a normal row, it´s too high. How did you solve that?

[chris-derrell]

I had both of those same issues, funny enough.

1. I had all the fields collapsed in the repeater items, revealed based on field type from the database. My layout had the fields setup two in a row, and I used the event context to collapse the container items I didn’t need visible, like _createdDate.

2. I had to take the datepicker out and place it above the form, and just capture the value when I sent it to the DB.

[plomteuxquentin]

Hi guys,

@givemeawhisky if think we are speaking about database schema, not markup schema. Database schema describe the structure of a database.

@Chris: I like your idea but database schema is very sensitive information and should not be available on the client-side. But I agree that such a feature would handy. Also, why not promise? If this is not a promise, it means that all page/backend need to load all collections structure at every time.

Now regarding your use case, I would create a directory config that hold all of your table schema as js files. The files would have a structure like

export default const structure = {
    fieldID: "wix_element_type"
}

for instance

structureForRoomBooking = {
   personCount: "slider",
   reasonForStay: "longTextInput",
   arrivalDate: "date",
   departureDate: "date",
   roomNumber: "numberInput"
}

So you get the idea.

It would be kind of easy for your client to add or remove a field that way.

On the frontend, you could indeed use a repeater with boxes to collapse all the field types that do not correspond to your “wix_element_type”

[chris-derrell]

I don’t think it’s as sensitive as you make it out to be you know. Every collection already has an option to " Collection Schema" when you’re exporting it.

Your suggested structure is a very great solution for the form! But it’s still an extra step on our side as developers (writing the config). I’m also imagining it with the new copy/paste feature being forms we can auto copy and lead between sites.

If that feature could be exposed through the API actually, that would be a solution.

[givemeawhisky]

Yes Quentin, I was just talking about the already existing Schema markup as I had it in my brain as was talking about it in another post.
https://www.wix.com/corvid/forum/community-discussion/critical-bug-using-seo-on-dynamic-pages-not-solved-for-4-months-and-today-solved-in-4-hours

Although, as Chris mentioned previously, the fact that Wix already provide a way for doing a collection schema, plus as stated in their own API Reference - Wix Data API works with a schemaless database although each collection has a non-enforced schema that you should conform to.

Then in theory we should at least be able to access this somehow, even if it isn’t capable through it’s own API as of yet.