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
Do you see value in adding a mock data capability to SDK taps? In the spirit of #1009 and MeltanoLabs/Singer-Most-Wanted#90 (comment), the idea would be to generate mock records for each stream based on their schemas (JSON Schema property type, format, enum, etc) using Faker - possibly reusing/refactoring the current stream maps implementation. This is obviously already possible with stream maps today, but would require stubbing out each stream property individually - the aim is to streamline this process; reduce the amount of necessary config and assume sensible mock values. Another benefit would be for taps with statically defined schemas that would be able to run without any config or connection to the source as a result, allowing for quick onboarding/prototyping. This would also work for taps that perform dynamic discovery, although config would still be required (in most cases).
Spec
New MOCK (or similar) capability, which exposes some SDK-native settings
capabilities:
- MOCK
# perhaps these could be declared per-stream, although some overlap with stream mapssettings:
- name: mock_enabledkind: booleandefault: false
- name: mock_recordskind: integerdefault: 10
Underlying Faker instance seed and locale configurable with faker_config (as with stream maps)
Inference of Faker provider from just JSON Schema property type/format is fairly straightforward - it may be possible to resolve a more accurate provider in a more granular context when taking the property name into account (this would be more of a "best guess", however)
With Meltano: warn if running meltano config <tap> test with mock_enabled: true, as this may otherwise indicate a false-positive
The text was updated successfully, but these errors were encountered:
How do you imagine invoking a tap in "mock" mode? Something like MELTANO_EXTRACTOR_MOCK_ENABLED meltano run ...?
Other than your comment about meltano config <tap> test, do you think most of the work to enable this would be done in the SDK? Do you think non-SDK taps are out of scope for this feature?
Feature scope
Taps (catalog, state, tests, etc.)
Description
Do you see value in adding a mock data capability to SDK taps? In the spirit of #1009 and MeltanoLabs/Singer-Most-Wanted#90 (comment), the idea would be to generate mock records for each stream based on their schemas (JSON Schema property
type
,format
,enum
, etc) using Faker - possibly reusing/refactoring the current stream maps implementation. This is obviously already possible with stream maps today, but would require stubbing out each stream property individually - the aim is to streamline this process; reduce the amount of necessary config and assume sensible mock values. Another benefit would be for taps with statically defined schemas that would be able to run without any config or connection to the source as a result, allowing for quick onboarding/prototyping. This would also work for taps that perform dynamic discovery, although config would still be required (in most cases).Spec
MOCK
(or similar) capability, which exposes some SDK-native settingsseed
andlocale
configurable withfaker_config
(as with stream maps)Considerations
type
/format
is fairly straightforward - it may be possible to resolve a more accurate provider in a more granular context when taking the property name into account (this would be more of a "best guess", however)meltano config <tap> test
withmock_enabled: true
, as this may otherwise indicate a false-positiveThe text was updated successfully, but these errors were encountered: