You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Those tests should probably be all run in its own suite for convenience.
However taking into account that there are also options for filtering/whitelisting data those tests should operate on a blockchain that has already some data - at least in tables/columns that we want to filter - so that may mean that maybe tests should be run at the end - after regular cluster tests.
if there is new table named address and has entries:
sancho_test_address_table=# select * from address limit 3;
id | address | raw | has_script | payment_cred | stake_address_id
----+-----------------------------------------------------------------+------------------------------------------------------------------------------------------------+------------+--------------+------------------1 | FHnt4NL7yPXqn7xha3WB99wYLxAc1FhceD3D1pQWaCthk9RYB46aGb6Tbq2KxV5 | \x82d818582483581c3f5eb76562f6db207efc47b65358d3ae00532e713a53a80f28d50ccca1024104001a61c9dd78 | f | |
2 | FHnt4NL7yPXwj8m191s48v1RZtQqA2sVHpamzStuXTuAnzYUSR6hRPqhYmW3MY4 | \x82d818582483581c6795076654af812180cc1690a5e83183cb9ee8c7b3e4071ebcddfb89a1024104001adfae7639 | f | |
3 | FHnt4NL7yPXzVZ5xexcb7rWqCYWuFU7y6Pp4tLTiv6txhDcpQ2m7AFGMirsi1F1 | \x82d818582483581c7a4786ea46c1b33e6b74d32182b70692bcdd93c9bff81ccc3aa21ce5a1024104001ab6a90594 | f | |
(3 rows)
if there is a new column in tx_out table named consumed_by_tx_id and it has some non null entries:
sancho_normal=# select count(*) from tx_out;
count
-------52036
(1 row)
```sqlsancho_normal=# select count(*) from tx_out where consumed_by_tx_id is not null; count ------- 1015(1 row)
We also need to check if tx_in table has entries - if "force_tx_in" was not present we would need to check if table is empty.
sancho_normal=# select count(*) from tx_in;
count
-------1015
(1 row)
Possible difficulties
If user starts db-sync with some set of config values it is not possible to stop and start and continue with different values.
For example - from using "consumed" for tx_out user can't go back to "enabled", only "prune" will be accepted.
From "prune" we can't go back to "consumed".
Once "use_address_table" is set to true, user has to continue with that setting or drop database and start a new sync with false value for that setting on a new empty database.
That means that db-sync database should be deleted before each new config test - other option could be to try to force some order of tests but I am not sure if this would be the best approach.
The text was updated successfully, but these errors were encountered:
Feature Request: Automation of db-sync new configuration.
Here is an example of new config file:
Those tests should probably be all run in its own suite for convenience.
However taking into account that there are also options for filtering/whitelisting data those tests should operate on a blockchain that has already some data - at least in tables/columns that we want to filter - so that may mean that maybe tests should be run at the end - after regular cluster tests.
Examples for whitelisting
Example of test flow
Tests case for new feature - extracting address table
We start
db-sync
with this config and check:are reflected in the db-sync logs:
address
and has entries:tx_out
table namedconsumed_by_tx_id
and it has some non null entries:tx_in
table has entries - if "force_tx_in" was not present we would need to check if table is empty.Possible difficulties
If user starts
db-sync
with some set of config values it is not possible to stop and start and continue with different values.For example - from using "consumed" for
tx_out
user can't go back to "enabled", only "prune" will be accepted.From "prune" we can't go back to "consumed".
Once "use_address_table" is set to true, user has to continue with that setting or drop database and start a new sync with false value for that setting on a new empty database.
That means that
db-sync
database should be deleted before each new config test - other option could be to try to force some order of tests but I am not sure if this would be the best approach.The text was updated successfully, but these errors were encountered: