Does Bubble really know what time it is?

I’ve recently observed two problems with Bubble’s handling of time (date/time).

I have a very simple sequence of workflow actions. (It exists to observe much bigger timing issues that will be diagnosed later, but this very simple problem makes the real job impossible.)

Here’s the workflow:

Pretty simple, huh? It is the first part of the Page is loaded event. (There’s much more that I need to analyze but I can’t do that until I understand how long it takes to write a log record.)

Here’s the result after two runs:

It appears that the first Create took about 46 hundredths of a second (14:09:30.47 - 14:09:30.31)

What is going on with the second set? How is it that the first log entry (14:09:48.26) was created after the second one (14:09:48.23)?

Oh, and just for fun, why is it that Bubble’s App Data viewer doesn’t show and obviously doesn’t sort on the full date, down to the fraction of a second it stores?

Without the partial seconds, to the greatest possible level of precision, it’s impossible to tell what sequence records were written in. (Isn’t that carrot symbol supposed to symbolize sorting in ascending order?

A few observations that may be useful for you:

  • Actions for writing to the database don’t always take the same amount of time. Additionally, actions are often run in parallel (not in series). So, sometimes the 2nd action will finish before the first, even if they do pretty much the same thing.
  • You can export data from your database and it’ll show the full timestamp, including seconds and milliseconds. But, it doesn’t do that for the logs. We’ve submitted a feature request for this in the past because there are instances where it’s not only helpful but almost essential. I believe it’s included in Bubble’s backlog.
  • One added point of potential complexity with time is that time can be referenced from the Server and from the user’s computer depending on where/how the time value is used (and those times can be a bit different). For times stamps in the database, I’m pretty sure Bubble always uses the server’s time for this (and not the time on the user’s computer). Some of the client side interactions, such as setting the current time in a custom state, are done based on the user’s computer’s time (which may be set fast or slow compared to server time). Bubble has added logic to ensure they handle scenarios where the two numbers (server time & user’s computer time) are off by more than 30 seconds (or something like that), which we’ve found usually works but not yet 100% of the time.

Thanks, Scott. I appreciate the quick and thoughtful response.

Some responses to your bullet points.

  • The whole matter of multi-threading (running in parallel) is beyond my understanding at this point. But whatever it means in practice, when a time value is given to a log record as its Created Date and Modified Date, why would it not sort down to the milliseconds in the Search results for populating the repeating group? Why would 26 sort ahead of 23 in an ascending sort?
  • I’m glad you submitted a feature request because exporting is far too unwieldy for the purpose of making and analyzing small adjustments to program code. Everything you need should be provided in the Editor and available display transformations so you don’t have to go outside the development environment to tweek, observe, debug and repeat.
  • I appreciate that time can differ between server and user. That shouldn’t be a factor in creating things (e.g. writing to a log table). Create a new thing should be either server-side or user-side consistently, not one or the other randomly.

Again, I thank you for your thoughtful reply.

@sridharan.s’s observations are spot on and helpful as always here, but I kinda have another suggestion for you:

It sounds like you’re really trying to do (rather than do down-to-the-millisecond analysis of some workflow) is to force some steps in a workflow that are being executed asynchronously (which is usually desirable) to execute synchronously.

If you want to force such a condition in a workflow, you can do it by inserting a pause step. Step 1 → Pause (doesn’t matter the length, it can be whatever the minimum is) → Step 3.

Inside of Bubble, this basically creates (maybe actually literally DOES) create an “await” type of event (if you’re familiar with JavaScript stuff). Basically, the Pause step awaits completion of Step 1 and will not do its pause thing until Step 1 is actually complete. Step 3 will not begin execution until the Pause step has completed (it awaits completion of that step).

It is possible to have situations where doing this is desirable, but they’re really pretty rare. Usually, synchronous execution vs asynchronous execution of workflow steps is handled just fine.

But one way that Bubble “figures this out” (if you will) is that some later workflow step refers to “the Result of” some earlier step. Most (all???) workflow actions report a “Result” that later actions can inspect in their “Only when” field. So this is a more natural way of ensuring that some later step does not execute until the previous step is done.

(Because whether the Result of the previous step is “empty”, “not empty”, some value, some thing, etc. can only be evaluated after that step has completed.)

@mishav explains it pretty well in this comment on one of your previous posts:

1 Like

Thanks, Keith.

I’m not trying to force sequential execution (although that may come in at some point.) I’m trying to get a page to load in a reasonable time frame. It is not, and I’m trying to figure out why and what to do about it.

Basically, I’m trying to get a sense of what part of my normal page load process is taking so long. I am writing to a log table as the only means I have to get a series of snapshots that might shed some light on what’s happening.

Unlike the “good old” (bad old?) days of Visual Basic and client server architecture, I have no idea what’s going on with “web apps”, AWS, browser vs. server execution and generally who’s doing what to whom. What I do know is several things so far and these discoveries have taken me far too long over the past two weeks:

  1. What I could do long ago in a client-server environment in one or two seconds is taking up to 15 seconds or longer to complete with Bubble. (Simply load up a page with task information and some related project info, and fill a few drop elements with database values.)
  2. The debugger doesn’t show you what is really happening. It just regurgitates what the app is asking Bubble to do. If Bubble fails to operate correctly, the debugger is of no help in figuring out what really happened.
  3. Bubble cannot be relied upon to set the value to empty for a custom state of type date.
  4. The time to simply load a page without doing any of the necessary database work is very quick. It’s the database work and/or the overhead of reusable elements and custom events that seems to be inflating the app’s load time.
  5. Bubble provides very clumsy and limited manipulation of time. It stores time (date with time) to the precision of milliseconds but doesn’t let you use that information.

I don’t need to be perfectly precise and consistent from run to run, but I could get a better idea what parts of the app are slow if I could see milliseconds in time intervals.

Happy to do so. To your first bullet - I suspect Bubble sorts in that order because it’s not loading the seconds and milliseconds to the UI. It looks as if it’s ordered based on the text value (and not the full timestamp).

I agree that this isn’t ideal, and presume this was easier to implement when they did so.

1 Like

I believe the creation of Bubble was initially driven by the over-arching idea of being “code-free”. With that came a philosophy of making things as simple as possible for non-coders to get in and make something.

Attempting to make things simple means hiding some details that actually exist under the covers, e.g. milliseconds. I don’t think it was easier to present time without milliseconds. I think it is what Bubble’s creators thought was best for non-coders.

If milliseconds exist in base object, it takes some work to eliminate them for presentation. Looking at the doc for Date Interval type:

:format as seconds
Formats the difference as a number of seconds. We divide through by 1,000 milliseconds and round to the nearest whole number

They could just as easily provide a transformation :milliseconds in which no division is needed.
Better yet, how about :as number, with the result being of type Number and the value being milliseconds. Then the developer would be able to calculate whatever was needed.

A lot of the raw material is inside Bubble.

This topic was automatically closed after 70 days. New replies are no longer allowed.