JOIN US! September 2, 2022 for a Wappler MeetUp

Aloha Fellow Wapplers,

Join Us September 2, 2022 @ 4:00PM Netherlands for our next Wappler MeetUp. What’s it about? . . . Shhh! It’s a Surprise!

You can find 4:00PM Netherlands in your time zone here: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Wappler+September+2%2C+2022+MeetUp&iso=20220902T16&p1=1302&ah=1

Here is a Zoom link for the MeetUp:

Passcode if needed is: WapROCKS

Here is a .ics file compliments of @sitestreet

We want to make you even more famous than you are AND support this fantastic community at the same time. All it takes is demonstrating your favorite Wappler feature or site. Reach out to @mark1 to set a date. Thanks!

Cheers,
Mark

6 Likes

@Hyperbytes

Hey Brian,

I believe this was the community meet up that you were presenting on. Thank you very much for doing that, sadly I’m based in Australia so was fast asleep during the live presentation. But I watched it the next day and have a few questions if you wouldn’t mind me asking. (database questions)

  1. you were creating integer/string fields, using them as foreign keys to reference other tables, can I ask why not using the reference field? (let me know if I’m misunderstanding (coming from bubble.io))
    See image below for red mark next to what I’m referring too, those id fields (creator_id) would be referencing the user id right?)

  2. (I’m planning to test this myself) But with sub tables in wappler, how does that change the database design? like for example if I was to create a subtable, and then connect to database by (navicat, pdAdmin whatever), will the database structure be same as making like to tables instead of sub tables?
    (from my last check, sub tables in wappler, was still just normal tables in database) so I am assuming that its more just a wappler feature to help build more efficient queries with the query builder. Am I on the right track?

Again huge thank you for the live presentation, and also your video series, I watch them as soon as they are uploaded.

Side note, id love if you could share the project in the video tutorials on github, so I can clone and mess around with it and reference it for specific details I might get stuck on.

Hi haydn, thanks for the feedback.
Firstly yes, reference fields could be used, I guess it is really a matter if choice. The primary reason the structure I used was as the presentation comes from the roots of my earlier video “joins, subtables and multireferences” where it was a bit contrived to demonstrate all those techniques.
2.Outside wappler such as in Navicat, each table will indeed appear as separate tables, Wappler does the hard work in showing them in their linked form by reference to it’s internal stored database schema.
I will be sharing the project via GIT and as a simple Zip file soon. One of the great benefits of using the wappler inbuilt server and SQLite is the entire project AND database can be shared as a single zip file where with git the database structure has to be managed separately

1 Like

Thank you very much!

Ill go find that earlier video, I might of missed something.
But from what I can tell not really any benefits or cons from using a general fields vs reference?

Awesome, looking forward to it :slight_smile:

Only real difference us by using a manual join you have more control over the type of join. Inner join will effectively fail the entire query if no join can be made, a left join will return the query with the failed join data replaced with a null.

1 Like

Ahhhh thats ringing some bells now. Thank you for clarifying :slight_smile:

I think you have led me to illustrate an important point. There is no “best” way to do anything, the method used will often be dictated by the nature of the result needed rather than the method to produce it.

100% agree, its me just trying to determine the pros and cons of each method. The beauty of wappler, so many ways to do things, but also a downside coming from bubble, where this a lot more restrictive, I think I’ve been focusing too much on getting perfect method first before anything. (pre-optimisation)