3. A record sequence is the reference of table sequence records
Obviously, if each computation on a table sequence is to produce a new table sequence, a great deal of the memory will be used. For instance, a table sequence, Order_Books, has 50,000 records, and 30,000 records are obtained by query. If new table sequences are to be created, there will be 80,000 records in the memory. In fact, as the queried records are part of the original table sequence, it is unnecessary to create table sequences anew. We simply store their references using certain data objects. These data objects are a record sequence.
3.1 Transparency of record sequences
Usually, it’s not necessary for users to differentiate between record sequences and table sequences, as what they do with references and physical data. For instance, operations like query, sort and intersection in the previous example can be performed on both record sequences and table sequences with the same syntax:
| A | B | |
| 1 | =file(“Order_Books.txt”).import@t() | =A1.dup() |
| 2 | =A1.select(Amount>=20000 && month(Date)==5) | =B1.select(Amount>=20000 && month(Date)==5) |
| 3 | =A1.sort(SalesID,Date:-1) | =B1.sort(SalesID,Date:-1) |
Note: A1 is a table sequence, from which the record sequence in B1 originates. The computed results in A2, B2, A3 and B3 are all record sequences.
Sets operation can be performed between record sequences, for example, the computation of orders in 2.2 A table sequence is a special sequence. But there isn’t any practical significance to perform sets operation between table sequences, for members of different table sequences are always different objects and the intersection of them is always empty.
When data structure changes, esProc will automatically create new table sequences, like what happened in the preceding example when groups function is used to group and summarize data, or new fields are added to a table sequence using derive function.
3.2 A table sequence has a one-way influence on a record sequence
Different table sequences represent different physical records, so modifying a table sequence will not affect the other ones. But, a record sequence is the reference of the records of a table sequence and the two have the same physical data, any change of the table sequence will affect the corresponding record sequence. For example:
| A | |
| 1 | =file(“Order_Books.txt”).import@t() |
| 2 | =A1.select(SalesID==363) |
| 3 | >A1.modify(3, 1:SalesID) |
Click in the toolbar for stepping through the program, and you will see the table sequence, in which SalesID of the third record is 363, in A1 as follows:
A2 selects from the table sequence all the records whose SalesID is 363, and creates the corresponding record sequence as follows:
A3 modifies the third record’s SalesID of the table sequence in A1 into 1. Check the table sequence afer the code is executed and you can see that the third record has really been modified:
Then check the record sequence in A2 and you will find the corresponding record has been modified too, though it wasn’t modified directly. This is because the records of the record sequence originate from the table sequence:
If there are multiple record sequences that originate from this same table sequence, their data will change accordingly.
In most case, this is not what a programmer wants to see. Take the above case as an example, in the selected data in A2 there appeared records in which SalesID is not equal to 363. This is because the modification of the table sequence data in A3 was executed after A2 had selected the required data (In this case, the corresponding reference didn’t change accordingly). Sometimes this kind of operation would cause an error in business
In order to avoid the error, users should finish modifying the table sequence before the record sequence is created. For example:
TSeq.modify(5, 1000: Amount) / Modify the field Amount of the records in which OrderID equals 5 into 1,000, i.e., less than 2,000.
RSeq =TSeq.select(Amount>2000) / The records in which OrderID equals 5 won’t appear in the RSeq.
| A | |
| 1 | =file(“Order_Books.txt”).import@t() |
| 2 | >A1.modify(3, 1:SalesID) |
| 3 | =A1.select(SalesID==363) |
First modify the data in A2, and then select the desired data. In this way, the record sequence obtained in A3 is as follows:
This computed result is what the business is required. It’s only natural for the above computing order as long as the reference relation between a table sequence and a record sequence is understood.
It’s important to note that operations to modify the original table sequence, like modify function, are not accepted in a record sequence. The relation between the two is a safe one-way influence. So users can safely use record sequences and table sequences.