is there a simple way to get a child stream to use...
# singer-tap-development
d
is there a simple way to get a child stream to use a replication key that isnt partitioned by the child context? As in, all child stream partitions share the same replication key value?
I tried setting
state_partition_keys
to
[]
which seems to almost get me there, but it looks like the state post-sync never gets the progress markers promoted to replication keys:
Copy code
{
  "bookmarks": {
    "merchants": {},
    "transactions": {
      "replication_key_signpost": "2022-09-02T18:31:50.388980+00:00",
      "starting_replication_value": "2022-06-01",
      "progress_markers": {
        "Note": "Progress is not resumable if interrupted.",
        "replication_key": "transaction_time",
        "replication_key_value": "2022-08-31T15:17:02+00:00"
      }
    }
  }
}
e
Hi @david_wallace ! Have you tried setting the
is_sorted
attribute of the child stream to
True
?
d
I have! didnt seem to have an effect. my hypothesis is that this is due to the fact that we muck around with
context
during ingestion (we add some keys to it)
e
my hypothesis is that this is due to the fact that we muck around with
context
during ingestion (we add some keys to it)
Ah yeah, that may be it. Issue’s probably around this line: https://github.com/meltano/sdk/blob/be8e0eb51a4e53dea790ef06dafa48c5067cda92/singer_sdk/streams/core.py#L1019
d
bingo
fwiw, i find myself needing to pass some arbitrary extra info to stream methods quite often, and I just assumed thats what context was for. it would be really nice if there was some sort of facility for passing arbitrary metadata through the stream components
a
i find myself needing to pass some arbitrary extra info to stream methods quite often, and I just assumed thats what context was for. it would be really nice if there was some sort of facility for passing arbitrary metadata through the stream components
This would make a really good feature proposal if you want to make an issue. Class-level and object-level declarations are tricky because the same class may be invoked several times, and the same stream object (at least as of now) may handle calls for multiple parents or partitions. All that said, it's certainly something that could help out developers, I think.
To the issue of stream state not being finalized - is this even after the tap finishing the other streams and shutting down normally (with success)?
If the SDK is not finalizing states for progress_markers at the end of the Tap's execution (and all streams were successful), then that would probably be a bug.
d
This would make a really good feature proposal if you want to make an issue. Class-level and object-level declarations are tricky because the same class may be invoked several times, and the same stream object (at least as of now) may handle calls for multiple parents or partitions.
All that said, it’s certainly something that could help out developers, I think.
cool - I can def write up an issue this weekend @aaronsteers
To the issue of stream state not being finalized - is this even after the tap finishing the other streams and shutting down normally (with success)?
yep! this is after all streams finish successfully
can try to collect some logs to show ya
a
👍 Thanks!!