APP DB Updating

Good day Domosapiens

As previously explained in Dojo, I'm working with the APP DB technology, trying to emulate a website within Domo.

I got my input form working with it's own dataset

Additionally I'm trying to make an update form, where after querying my results, I want to be able to modify that same record by its __document_id__ auto generated field.

Any help with this will be fully appreciated, as for now my approach to a solution is:

-Query results from the input dataset

-Work on my updates, execute the command

-Create a copy of the input dataset, but specifically for updated data

-Save data in this new dataset and link it to my stats cards

Let me know if you need code or snapshots from my development.

Thanks in advance.

Find more posts tagged with

Comments

DomoJesseK

Hi Martin,

Do you need to separate the original data from the updated data?

MartinB

Right now, that is my proposed solution, but there is no real need to separate the data after updating.

I assumed that, based in the APP DB documentation, it wouldn't be neccesary to separate the data, as only 1 dataset would be needed.

I've come across with some unexpected behaviors, at least for me, like for example:

Dataset created with the input form project, is only readable from that particular project. To retrieve data from the updating form, I have to use SQL commands and display the results in the DOM.

List documents command doesn't work in this instance

domo.get(`/domo/datastores/v1/collections/Users/documents/`)
    .then(data => console.log(data));

Nor the list by documentID, not to mention, Update Document(s)

Similar/related to this, after defining my original schema, it won't take my updates. Let's say I want to add a new column to the schema, well instead of adding it to the existing one, it creates a whole new dataset with 0 rows but adding the new column, leaving the original one with N rows intact from the update.

DomoJesseK

You're correct that the store is app-instance-specific. You can only read/modify docs from within the app that created them. However, if you're syncing the store to a dataset, you could access that set from another app.

That being said, you should be able to both list and update docs within that app. Have you already published the app and are testing locally?

MartinB

Thanks for the answer.

Sadly, being able to modify datasets only from the project where they were created won't work even remotely for me Smiley Frustrated

@Jesse wrote:
if you're syncing the store to a dataset, you could access that set from another app.

That being said, you should be able to both list and update docs within that app. Have you already published the app and are testing locally?

Can you be a bit more specific on this please?

Yes I've uploaded my 2 projects (input and modify) to my Domo instance.

DomoJesseK

Assuming you were referring to publishing the app and testing locally...

Hitting AppDb can only be done on your local machine through a proxy in your local dev environment. When I've developed apps that interface with AppDb, I found it easier to just test that interaction within Domo, after publishing the app. Otherwise, without a proxy, you won't get results locally.

From the documentation:

...you will not be able to make these calls in local dev without including a proxy.
Instead, you must publish your app and ensure that it is making calls in an installed app.

MartinB

@Jesse wrote:
Assuming you were referring to publishing the app and testing locally...
Hitting AppDb can only be done on your local machine through a proxy in your local dev environment. When I've developed apps that interface with AppDb, I found it easier to just test that interaction within Domo, after publishing the app. Otherwise, without a proxy, you won't get results locally.

From the documentation:
...you will not be able to make these calls in local dev without including a proxy.
Instead, you must publish your app and ensure that it is making calls in an installed app.

It's done. I've published the app into Domo since I created it, as not even the domo.dev command works without publishing the app first.

Domo dev won't either bring query results, all what I've said has been done within Domo.

DomoJesseK

Gotcha. I think I might have misunderstood the issue...your goal is to allow a user to enter data into a custom app, then potentially update that data, while you surface the current state of those records within a card/cards. Is that right?

If so, this can all be done within a single app. Let me know if I'm tracking correctly and I'll provide some options.

MartinB

Yes, exactly.

Flow will go like this:

1. User will type in information into the form and submit it to be saved in the dataset

2. Admin User will go to a search form, where an employee number will be typed in and data from that employee will be retrieved. In that result form, admin user will be able to add new data to a specific set of fields, and submit that to be saved in the dataset

3. This data (starting from step 1) will feed some charts and tables, and when updated (step 2) I'd like to see the refreshed results in the charts and tables.

My front end development is pure HTML5, CSS3 and Javascript

I would asume this can be done in only 1 dataset, with the Update Document by ID command. Also, as mentioned before, I had to create 2 domo init projects, one for the initial input form, and another one for the search results and update form.

Hope this helps, thanks again!

DomoJesseK

Got it. Thanks for clarifying.

You have a few options:

Single app/store to both capture and administer data. Under this model, you could use the `env.userId` property to determine if the current user is an app admin (either hardcode the admin user ID's [easier] or query them from a dataset in Domo [better]). You could then use that "is admin" flag to enable the admin UI, including editing and the search control. All of this would occur prior to step 1, below...as soon as the app is loaded. You would also sync the AppDb store with a dataset, enabling your cards/flows to be build off a single set of data. This is a little easier in terms of maintainence and you gain ease of code reusability. However, there is a risk here...you'd be applying the admin logic in your javascript, which could be changed by a saavy non-admin to allow them to edit. Based on what you're capturing, this may not be an acceptable risk.
Separate apps to capture/store and edit/store, plus data flow to combine. Under this model, you'd have separate capture and admin apps (similar to what you described). The capture app would write to a single store, which you would then sync with a dataset. You could then query that dataset into the admin app and add it to that store as well, also updating the admin-related fields you want. You'd have to create a custom upsert-type process to achieve this, but it shouldn't be too difficult. On every use of the admin app, you grab the latest data from the synced-capture dataset and upsert it into your admin store. You could then sync the admin store with a dataset and use a dataflow to produce an output set that left-joined the capture set to the admin set. You'd build your cards from that set. This model may increase code duplication, but does allow you to handle security using Domo's native sharing controls...only share the admin app with your admin users. If your capture store is syncing every 15-mins with its set, you'd have up to a 15-min delay between data capture and an admin's ability to edit that same record.

Let me know if that's not clear and I can draw up a quick flow diagram to help illustrate.

Do you think either of those would work?