Trying to understand Virtual Lists schema

[Rich]

Greets, all:

I downloaded this instructional file (https://www.seedcode.com/virtual-list/) to learn about virtual lists and I'm stuck trying to understand how part of it works, so maybe the wizened among you can explain it to simpleton moi; I'm in the corner wearing the pointed hat.

After the Contacts script runs, the Interface Records layout is populated with records from $$VarContent, but I can't figure out how that layout gets populated with individual records from $$VarContent; the data within that global variable is return delimited, so how does it from that to individual records?

 

VirtualList.fmp12

[comment]

11 minutes ago, Rich said:

the data within that global variable is return delimited, so how does it from that to individual records?

Do you understand what this:

GetValue ( $$VarContent ; RecordNo )

does?

[Rich]

I do, but I still don't get how individual records are created since there's no part of the script--that I can tell--that creates individual records in Interface. That, and I can't see how the RecordNo field (in the Interface table) becomes populated with a record number(?) 

 

*heavy sigh* Time for more coffee.

[comment]

AFAICT (I only glanced at the file) the records are pre-created and there is an assumption that there is enough of them for all planned uses.

 

Edited October 15, 2019 by comment

[Wim Decorte]

That is correct: the virtual table needs to have sufficient records already created.

You could loop and create records yourself but that would make it not multi-user safe.  So pre-populate the table with enough records for what you will expect to find in $$VarContent

 

 

[LaRetta]

On 10/16/2019 at 5:43 AM, Wim Decorte said:

That is correct: the virtual table needs to have sufficient records already created.

You could loop and create records yourself but that would make it not multi-user safe.  So pre-populate the table with enough records for what you will expect to find in $$VarContent

Hi Wim!  Can you explain this a bit more?  How might users collide if creating multiple records?  Do you mean because the file was numbering the records or did you have an additional concern? 

[Wim Decorte]

Since the concept of virtual lists revolves around unstored calcs: each user will get their own results in their own session for the existing records.  In that sense, the actions of one user do not affect any other users.

But if users start creating and deleting records they may be affecting the results of another user's session.

[comment]

6 hours ago, Wim Decorte said:

But if users start creating and deleting records they may be affecting the results of another user's session.

Deleting, yes - but creating? How would that affect another user?

[Wim Decorte]

I've seen it happen where the same Virtual list was used for multiple purposes and one of those uses had a very nice "pagination" going on.  Showing records in increments of 25 with "next page / previous page"

For another use a user was creating records that upset that other carefully crafted pagination.

[comment]

Sorry, I don't get this. If the records are auto-numbered (as IMHO they should be), then adding new records should not disturb a "carefully crafted pagination" - or anything else, for that matter. 

[LaRetta]

I'm struggling to see it as well, Wim.  Is there any way you could create an example of it breaking - when using AE serial, for example?

[Joshua Willing Halpern]

I can't think of a multi-user scenario where it's safe to delete Virtual List records. But creating records should be fine if you use Auto-enter serial number to set the recordNumber field (like @LaRetta said).

I feel like it would be unsafe to use auto-enter calculation of `Get (recordnumber)` because if User A and User B are creating records simultaneously and they both create a record before either one commits, you might get a duplicate value in the recordNumber field. Is that right?

Edited October 20, 2019 by Joshua Willing Halpern

[comment]

Auto-entering Get (RecordNumber) can easily produce duplicates even for a single user: just omit some records before creating a new one. However, an unstored calculation of Get (RecordNumber) would still work fine (albeit slower) for getting the correct data row into the record - though perhaps not for other purposes, such as the "pagination" mentioned earlier. 

 

Edited October 20, 2019 by comment

[Joshua Willing Halpern]

1 hour ago, comment said:

Auto-entering Get (RecordNumber) can easily produce duplicates even for a single user

Right, i'm thinking in terms of if you "do everything right", rather than ad hoc record creation by a user. I.e. go to layout, show all records then start creating records. That would prevent the omit/found set issues that could arise, but I believe we still might get duplicates if two users created a record n "at the same time". Disaster could probably be averted with unique field validation, but it's just not worth the hassle. Rather auto-enter serial is the way to go because the source of truth about the next "record number" isn't tied session/context/found set.
 

 

1 hour ago, comment said:

unstored calculation of Get (RecordNumber)

That totally works as long as you don't need to sort/filter the displayed results. For that we need a stored recordNumber field.

But to bring it back home, I think auto-enter makes record creation safe in multi-user environments, when used with some simple precautions like always showing Virtual List results as a found set or in a portal so the user doesn't see extra empty rows magically appearing at the end of their report.

[Wim Decorte]

@LaRetta @comment No breakage in the data itself but merely a breakage in the display of data, since clearly the original developer had made some assumptions on there always being only 25 records to display.  There are of course many ways to make it safer instead of relying on assumptions but that's not the point.  The point is that the developer didn't think he needed to.

Clearly not as potentially catastrophic as causing inaccurate data but it was a case of one user's actions affecting another user's session, which is what were talking about.

[Ocean West]

Many of the files i've posted in the Marketplace are examples of virtual lists.

 

[comment]

3 hours ago, Wim Decorte said:

No breakage in the data itself but merely a breakage in the display of data, since clearly the original developer had made some assumptions on there always being only 25 records to display.

I still don't see your point. I believe the way it should work is:

1. Count how many rows the data has (n);
2. Count how many records the table has (m);
3. If m < n, create (or import) records until m ≥ n;
4. Create a found set of n records.

Ideally, all this would be automated. But even if it's not, I don't see where "a breakage in the display of data" would occur if a user did it manually.

 

[Wim Decorte]

I don't have a point, I was describing an actual situation that I have seen where one user creating records in a Virtual List table affected another user's view of his data.

Not sure how to explain it better; it was clearly something that the original developer could have handled better to avoid the interference, but the interference was real.  Picture this if you will: a portal that is set up to show 30 rows but the developer intends to have 25 records to show.  Buttons over the portal to show "next page" and "previous page", buttons retrieve the relevant 'rows' from its source and the Virtual List calcs are set up to read from that.  All is well if the Virtual List table has 25 records in it.  Now some other user creates more records and that original portal now shows more than 25 records.

That's the scenario that I was describing.

It can be avoided many different ways of course, one way is not have sufficient records in the VL table and don't let users or their routines create records.

 

[comment]

My issue with your original statement is that it could be taken as a general limitation of the method.