How do I put this? I just can’t get my head around the concept of lists. I am used to relational databases but I want to take advantage of this new approach you have created. After a couple of days, I have watched the lesson many many times and I cannot translate that to what I am trying to do.
Can someone point me to a video or more extensive documentation on how to work with lists?
I have a TYPE(table) “Jobs” in it I have THINGS(fields) JobName, JobStart, ect. and Tasks(which is defined as list of TEXT)
I want to:
DONE - Add to the list of Tasks upon record creation. I figured out how create a new record via input fields; for example the JobName… and Task1 input field, Task2 inout field etc)
TOTALY CONFUSED - After the record is created, I cannot figure out how to Modify the Tasks field which is a list of text. I have a GROUP that is tied to a specific record in TYPE “Jobs” and all my input fields are binded to the record I am modifying or updating so they all update just fine. My question:
But how do I update/ change/ and further add to the list “Tasks” once I am viewing that record?
In a relational database scenarion I would just have another type(table-tasks) and link tasks to jobs. I know I can do this here too, but I rather try to shift to this LISTS paradigm you have created.
Any help would be nice, so I can get some sleep Hopefully this could help others looking at this for the first time too…
Lists are not really very much different to a Relational Database, you just don’t have to worry about all the Foreign Keys etc. In this case you are storing Texts in a list, so they don’t have their own data type, which makes it a little different.
You make changes to the Job thing using “Make Changes to a thing” action…
As you have a list of Texts, you can’t (AFAIK) amend the text directly, you would need to delete and add a new one.
This is different to having a new Data Type of “Task” and then having a list of Tasks on the Job. In that case, if you can amend the Task Thing’s Name (for example).
Thanks you very much. What I finally understood is that basically, the list is really a different Type or Table. If it helps anyone person new to this… here is my ahah! moment.
Since what I was interested was to have a complex list of Tasked for every project record, I finally understood that I had to make a type or table called TASKS with the following things/fields 1) task name 2) task date 3) task completed (y/n). So I created that table/type manually.
Then in my PROJECT type/table I added a field called ListOfTasks and made it a list of TASKS.
Now here is the trick in the WORKFLOW:
Step1) You first have to add each item (1) task name 2) task date 3) task completed (y/n)) to the TASKS type/table using the CREATA A NEW… (in this case TASKS). This creates a new record in TASK with all the content in the proper fields.
Step2) Now you can add that record to the field in the PROJECTS type/table called ListOfTasks. The WORKFLOW provides Make changes to PROJECTS and also provides a RESULT FROM STEP 1 which allows you to add the record you just added in step 1 to the PROJECT TABLE in the ListOfTasks field.
Step3) Do some screen clean up to resent the values used in the input fields.
I love this! once I got it. Now I have a complex Repeating Group of Tasks that are also “binded” the containing group (projects). So users can simply edit the items directly in the Repeating Group of Tasks.
In this case the list is really just a One-to-Many relationship, so when you Add the Task to the ListofTasks on Project you are doing a far simpler ForeignKey/PrimaryKey link.
The difference with Bubble (which is a bit like an Object Relational Database) is that if you have a Task thing, you don’t need to know all the complexity on how to Join to the parent.
If you want to show the Parent Project’s Name next to a Task … Task’s Project’s Name.
Or back down the other way … You could show the most recent task date on a project … Project’s List of Task’s Start Date : first item (sorted by start date).
You traverse the table joins with apostrophes, which makes it really readable…
I am a new Bubble user and have been blown away by the product. However, I am an old 3NF database designer, and I struggled to get my mind around the different Bubble paradigm for data handling. I spent 3 days trying to add billings to a member record, without success. Then I read your post and solution, and hey presto, it was done. Thank you so much.
I suggest that Bubble add a specific section to their manual explaining this data handling paradigm shift for experienced developers who are new to Bubble. It would have saved me a lot of time.
As an ex database person as well (who is so old he remembers getting excited about relational databases !) I am interested in the disconnect you are having between classic relational … and Bubble’s database which I snappily refer to as “a simplified Object Relational Database build on Postgres”
Is it the Foreign Key <> Lists of Things part ? Or storing arrays of texts (which is not very 3NFy but can be done in several RDBMSes) ?
When trying to add a BILLING record to an existing list of BILLING records linked (attached?, embedded?) to the MEMBER record, I figured I would change the BILLING record in the CURRENT MEMBER record. It never occurred to me to add the BILLING record separately first (how would I link this to the MEMBER record?), then change the MEMBER record and BILLINGS ADD the result of the previous step.
It also took me awhile to overcome my 3NF fear of embedding the BILLING record IN the MEMBER record definition.
Once you understand it, your SORDBOP techniques are all very elegant.
I developed the following doc to record my understanding of Bubble vs 3nf differences.
Bubble data usage notes for traditional 3NF developers
Bubble has an elegant object based data management system .However this system may be unfamiliar to the more traditional 3rd normal form based data designers and developers. Some of the major differences between Bubble and 3rd normal form design are listed below:
A. 3NF Design
Tables contain records which contain fields
A. Bubble Design
Types contain things which contain fields
B. 3NF Design
All records must have a unique numeric ascending key which provides a unique identity for each record.
Although Bubble does provide a unique key for each record, this is usually not required as Bubble manages the relationships between records itself.
A one-to-many relationship between a primary table and a secondary table is defined using a foreign key to the primary table record embedded in the secondary table.
For example, field MEMBER_FOREIGNKEY would be added to the table BILLING to link it to the table MEMBER, when populated.
B. Bubble Design
A one-to-many relationship between a primary table and a secondary table is defined by embedding the secondary type as a list in the definition of the primary type.
For example, field MEMBER_BILLINGS of type BILLINGS would be added to the definition of type MEMBER.
C. 3NF Design
To add a new record to the many side of a relationship, a new secondary record is written containing a foreign key which points to the Primary Key of the one side.
For example, create a new BILLING record with MEMBER_FOREIGNKEY equal to MEMBER primary key.
C. Bubble Design
To add a new record to the many side of a relationship, add a new record to the secondary (many) type, then modify the secondary type in the primary (one) type using the result of the previous transaction.
For example, add a new record to the BILLING type, then make changes to current MEMBER with MEMBER_BILLINGS add Result of step 1
Hopefully this could help others looking at this for the first time too…
