Labels and listViews are not populating with correct TinyDB list info

[OES]

Hi all! You've been great so far! Super helpful.

Problem: labels and listViews are not populating with correct TinyDB list info.

Here is my latest challenge with my app. I am pushing the limits of what TinyDB can do, I think, trying to use it somewhat relationally when it is not designed to do that. I promise v2 will use something like FireBase, but I've promised myself that I would stick with TinyDB for my MVP since I have come this far.

So here's what I am striving to accomplish:

On a screen I previously successfully created, BE_Define_a_Role or Screen 3; the user is able to create a role, essentially a list under the tag "roles" with three fields: roleName, roleVision, and roleDOH.

Here's the blocks for that Screen:

On another screen I have successfully created, BE_Goal_and_Big_Rock_Define or Screen 5, the user can define a goal. They can also "assign" it to a role they created in Screen 3.

Here's the blocks for that Screen:

Now we're on Screen 6: BE_Role_Report. This are supposed to come together here. Here, the user is supposed to be able to select a created role from a listPicker, and then the screen will populate with as much data as possible where that role is associated.

It should

a) Display is labels details about the selected role: the roleName, the roleVision and the roleDOH.

b) Display is listViews details other details about the selected role, such as any goals that have been associated with that role (and NOT show any other goals.)

Here are my blocks for this screen:

Your ideas an opinions are cherished! Thank you!

EDIT: I forgot to spell out what is wrong exactly!

Error 1: Regardless of which "role" is picked in the listPicker, the same roles, vision, and DOH populate in their respective labels. The values that correspond to the first role always populate

Error 2: Regardless of which role is picked, all the goals popularte in the ListView in the bottom of the screen. It doesn't filter by the chosen role in the listPicker.

[ABG]

You didn't mention anything going wrong, so all I can advise are general cautions.

I worry about multiple versions of the truth, especially when juggling global variables, TinyDB values, and ListView Elements.

For simple structures like tables, TinyDB is capable of saving and returning data immediately, without the need for any global variable. That avoids extra initialization steps for global variables, in Initialize events that might be missed when transitioning screens in various environments.

If you want to update a table in TinyDB, copy it to a local variable from TinyDB, update it there, and immediately put it back into TinyDB.

That way, you don't need a global variable for it.

You could hide all that in get and set procedures for the table, if you want to keep some Elements lists synced with the table.

[OES]

You're right, I've edited my original comment spelling out the error in the following way:

Error 1: Regardless of which "role" is picked in the listPicker, the same roles, vision, and DOH populate in their respective labels. The values that correspond to the first role always populate

Error 2: Regardless of which role is picked, all the goals popularte in the ListView in the bottom of the screen. It doesn't filter by the chosen role in the listPicker.

[OES]

@ABG

You didn't mention anything going wrong, so all I can advise are general cautions.

I worry about multiple versions of the truth, especially when juggling global variables, TinyDB values, and ListView Elements.

For simple structures like tables, TinyDB is capable of saving and returning data immediately, without the need for any global variable. That avoids extra initialization steps for global variables, in Initialize events that might be missed when transitioning screens in various environments.

If you want to update a table in TinyDB, copy it to a local variable from TinyDB, update it there, and immediately put it back into TinyDB.

That way, you don't need a global variable for it.

You could hide all that in get and set procedures for the table, if you want to keep some Elements lists synced with the table.

You've given something to think about here. I'm not sure if I've played yet with using anything but local variables. I understand the concept of local variables, but not sure how to declare them in App Inv.

[ABG]

@OES

I understand the concept of local variables, but not sure how to declare them in App Inv.

Here is a library of list procedures to do relational operations in AI2.

select_where_equijoin.aia (10.9 KB)
Of particular interest:

I coded these before AI2 added the advanced list blocks which would have made these shorter.

[ABG]

P.S. It might help us to visualize your primary and foreign key structure if you were to lay out your three tables in a little Google Sheet and share it with us.

You would need it to have at least 3 sheets.

[OES]

I really appreciate you taking the time to post this. However, I am not at the place in my development yet where somewhere can throw up blocks or code and I can read it and deduce the lesson. I am still in my first few months of coding.

[OES]

@ABG

P.S. It might help us to visualize your primary and foreign key structure if you were to lay out your three tables in a little Google Sheet and share it with us.

You would need it to have at least 3 sheets.

This I can do! I think in terms of tables anytway, and can share with you a simple MRE I made a few weeks ago. Give me a minute.

[OES]

@ABG

P.S. It might help us to visualize your primary and foreign key structure if you were to lay out your three tables in a little Google Sheet and share it with us.

You would need it to have at least 3 sheets.

Thanks for asking to see my tables. Here is a screenshot with arrows.

This is Screen 6: Roles Report

1. The green arrows from the Roles table should a) populate the rolePicker with roles to select from b) then populate the label for role selected, roleVision, and roleDOH.

In TinyDB, this is tagged as "roles" (a kind of roles table).

2. The orange arrows should take the goals associated with the selected role and populate the Goals ListView with those record where the selected role for the Goal matches.

In TinyDB, this is tagged as "myGoals" (a kind of goals table).

3. The red arrows are for a screen I haven't developed yet: Projects. In similar fashion, on Screen 6, the Project ListView should be populated with projects that are associated with each project.

In TinyDB, this is tagged as "projects" (a kind of projects table).

I hope showing you the Entity-Relationship Model helps some.

Thanks!

[ABG]

The screen shot comes up very fuzzy on this board.

Can you supply a direct link to the sheet holding the model?

[OES]

Sure. It's here: Be-Do-Tables_Needed - Google Sheets

I'm struggling with frustration. I've beebn trying to get this solved for two weeks now (off and on, in between my studies) and I'm starting to think that TinyDB simply can't do this. I may have to pivot to using Firebase sooner rathert than later to get it to do what I want to do, which sorta means back to the drawing board because I know close to zero firebase.

[ABG]

Could you also upload an aia export?

You need custom value procedures to act as views into your tables.

[OES]

Sure. I'd appreciate any help.
BE_DO_v0_2024_08_30.aia (42.3 KB)

[ABG]

(for the board)

Roles-Vision-DOH
Your model:

The actual table as created:

Projects

Timeframes

Project-Status

Goals-Big_Rocks
Your model:

The actual table as created:

Project-Actions

Action-Status

Delegates

[ABG]

@OES

This is Screen 6: Roles Report

BE_Role_Report?

[OES]

yes

[OES]

you'll see a bunch of disabled blocks which was the approach I was using for a while there.

The enabled blocks that use procedures are the approach I have been using since yesterday.

[ABG]

I rewrote the roles report to use advanced list blocks and value procedures, to simplify it.

The list pickers are now populated with role and goal names, which are your unique keys (I hope.)

BE_DO_v0_2024_08_30 (1).aia (41.2 KB)

I could not proceed further with your other tables for that report, because you don't have code yet to populate them.

[OES]

I'm checking it out now!

Regardless of whether or not it works, thank you greatly for using your valuable time!

[ABG]

While we're on the topic of fitting relational ideas into TinyDB, I would be negligent if I didn't point out a nice feature of TinyDB to help access table rows by key in separate tables: TinyDB NameSpaces.

NameSpaces let you allocate separate XML files behind the scenes for different data you want to save in TinyDB.

If you allocate one NameSpace per table, you can use the tags as keys of the rows, and separate out each table into multiple tag/value pairs where the tag is the particular key value for that row and the value is the row. That gives you direct access if you want to update a row, and a taglist gives you a list of keys suitable for ListPicker Elements.

You can allocate multiple TinyDB instances in the Designer, rename them, and set their NameSpace values to match their name, like tdbGoals.

There is a recent TinyDB block that can extract the entire TinyDB instance as a dictionary, if you want to take the dictionary values (a list of lists, if you store rows as values), ripe for list filtering.