Skip to content

Latest commit

 

History

History
103 lines (84 loc) · 4.63 KB

todo.org

File metadata and controls

103 lines (84 loc) · 4.63 KB
Raw

Goal Numero Uno is Sourcerer Parity (direct and unadorned)

  • No tap-tester test
  • No features that sourcerer doesn’t have (lock down the version via the api-version header)

    We think this should be possible with the current oauth-flow. We will fail fast if that turns out not to be the case and fall back to authenticating via their token.

  • !!! We could really use an alpha tester but it’s not necessary. We only need to deliver something we think will probably work rather than something we’re pretty sure will work!
  • !!! We should not do field selection. It makes the sync logic much harder as you have a combinatoric situation of what among Events + Objects is selected and what records to emit because of it!
  • !!! Sourcerer stripe does not implement 429 support!
  • !!! Sourcerer does not update all objects. Only InvoiceItems, Invoices, Coupons, Plans, Customers, Transfers, and Charges.

    Is it possible that retrieving an object by ID merges all updates to it into its state but retrieving the same object from the Object’s stream has it as it was created?

  • @brian Do we need docs according to the contract?

Can the VM perform the oauth dance?

Add the form to the ui

Start with the assumption that we’ll be collecting a

Add oauth callback support for platform.stripe to connections-service

This is when we decide whether we can get the account-id or not.

Create the skeleton tap project based on singer-tap-template

Get a skeleton pylint build running in circle

Run a check job

# in orca
./run_it check <conn_id>

We need at this point to be using the account_id property or the api_key property.

This is probably good enough to do with an stripe.Account.retrieve(account_id) call.

Log the name, etc. of the account we retrieved.

Need to be sure to use the stable version of the API that we are currently using. Allowing customer specification of the API version needs to come later because it introduces too much uncertainty.

Implement the schema for Charges

Always selected. We will do field selection later.

Do a sync for Charges

Notably, we do not get updates for Charges at this time.

Handle rate limiting

This should be in line with the spike for =timeout=.

This is not a strict requirement because sourcerer doesn’t handle it. But we think it’s super easy.

Add Charges data typing

Add bookmarking for Charges

This is object cursor id pagination. See sdk.py.

Add Events stream

Because we are not doing field selection, this part will be easy.

Add Charges updates

Add Customers syncing

Add Customers updating

Add Plans syncing

Add Plans updating

Add Invoices syncing

Add Invoices updating

Add InvoiceItems syncing

Add InvoiceItems updating

Add Transfers syncing

Add Transfers updating

Add Coupons syncing

Add Coupons updating

The following get no updates according to sourcerer

Add Subscriptions syncing

Add BalanceHistory syncing

Add TransferTransactions syncing

Support start_date config property

v1

Test field selection

@brian: Do we have any reason to believe that field selection could be complicated for this tap? Are their field exclusions, etc?

Implement discovery for Charges

The schema may be tricky here. There are many deeply nested objects (See https://github.com/stitchdata/sourcerer/blob/f828820666363f15ab47bcff3a883f9fb14791f3/sourcerer/src/clojure/sourcerer/apis/datatype/stripe.clj#L113) but all of the data typing concerns appear to be around datetime parsing. We’ll need to put that in by hand unfortunately.

Add bookmark logic around Events / Object selection combinatorics.

How does sourcerer handle resetting your bookmark?