Already filed as a formal bug report, but here’s a very interesting one… Found this while deploying my new Calendar Grid Pro-powered calendars to grupz.com:
There seems to be a bug with :merged with operator and dates. This is apparently illustrated by the following page:
The 3 repeating groups on this page source a list of dates from my database. (These dates represent starting dates for bookings on the “Listing” object displayed by this page.)
There are 3 lists: The first is a list of dates that has many values in it (43 at the moment). The second and third are other lists of dates that – in this particular case – are empty.
When these 3 lists are merged, the resulting list is incorrect. Rather than having all 43 items from list 1, it has 20 items in it. The first 15 items in the merged list are correct. The 16th through 20th are items from list 1, but they are seemingly random.
This does not happen with smaller lists, apparently, as is shown by different database objects. See:
Just following up on my own report: I didn’t realize this as I hadn’t inspected the problem data set fully, but it turns out what I’m seeing is expected Bubble behavior.
The list(s) that do not merge correctly are lists that contain duplicate values. These values are sourced from an API and so, until touched by Bubble can and may contain duplicate values. (In this case, we are talking about lists of start dates and lists of end dates that represent booking start/end [check-in / check-out] pairs.)
The :merged with operator in performing the merge operation “Bubble-izes” the lists and, as expected, removes duplicates. But in this case that can break the expected pairing between these starts and ends.
Of course, it is entirely possible for such lists to contain duplicate values. As an example: The pair at position 1 in the list might represent 5/22/2019 to 5/25/2019. The pair at position 10 might represent 5/22/2019 to 5/30/19.
When processed with a Bubble list operator those 2 instances of 5/22/2019 will collapse into a single list entry.
So, not a bug, but expected behavior (I simply did not realize that these particular lists would sometimes contain duplicate values at different positions) that I need to work around.
(I did turn the bug report into a request for enhancement – it would be handy to have optional list operators that don’t result in de-duplication. Of course, I have workarounds for this, but ideally one desires these as operators, not as element/action/server-side-action plugins. Also, why is there no API for operator plugins, eh?)
