What Changed?

I added

• #build_truncate_statements - Update the functionality to filter out engines that cannot be truncated
• Added unit test to ensure functionality
• Added clickhouse/minitest.rb as a helper similar to clickhouse/rspec.rb

Motivation

In our production app we're using database_cleaner to do the truncation and taking advantage of it's except functionality (DatabaseCleaner.strategy = [:truncation, except: %w[widgets]]) to filter out specific tables. I'm hoping to remove our dependency on database_cleaner and allow clickhouse-activerecord to manage the truncation.

The pattern used here follows the ActiveRecord implementation. We currently rely on the abstract implementation for #truncate and #truncate_tables - active_record/connection_adapters/abstract/database_statements.rb.

Postgres and Sqlite use this same pattern to adjust their truncation methods

• postgresql/database_statements.rb - Overrides build_truncate_statements to truncate all tables in a single statement
• sqlite3/database_statements.rb - Overrides build_truncate_statement to use DELETE FROM since SQLite doesn't support TRUNCATE

Related to vantage-sh/core#13141

This test fails against master without the above PR merged in. With the changes, this test passes.

COMPLETES ENG-466

zbugs: Potential for a better error message when a table is referenced in a relationship but not included in createSchema

Thank you @arv for the work on #3477. It pointed me in the direction of where to look code wise. I wanted to expand the work that was done to resolve the issue I ran into where defining a destSchema for a table that isn't referenced in schema.tables causes an error.

I added test cases for two potential ways to have a missing table. If anyone can think of other scenarios I can gladly write more tests.

My only question about adding this, while I think it improves the DX and will help people to ensure their schema is valid, is there any concern about runtime cost and having createSchema doing this additional work?

I was trying to use bright to highlight the gleam language. Everything was in place in tm-grammars to do that, bright just needed to be able to access the newer languages. Updating to the latest release of lighter gives us access to the newer version of tm-grammars.

I'm not super familiar with lighter, but it also has a pinned exact version of tm-grammars, currently set to "1.16.2". It may be a good idea to relax that requirement so that new languages that get added can be accessed without having to publish newer versions.

Fixes: #203

Preface: This is my first exposure to working with these Node objects on the server side so I'm not entirely sure if what I've done is correct.

I changed the way the incremental responses are sent back to the client. In the issue I noted

      for await (const chunk of httpGraphQLResponse.body.asyncIterator) {
        body.push(chunk);
      }

this await is stopping the server from incrementally delivering the responses and instead they're all delivered at once.

These changes allow the responses to be streamed back instead of all at once.

The logs in the client now show

what is data? {book: {…}} false 12:22:18
what is data? {book: {…}} false 12:22:19

Where the second book: {} has the deferred data and is delivered 1 second after the first in which the 1 second is hard coded in my project using this package.

https://github.com/apollographql/apollo-client-nextjs/pull/309/files#r1628079676

As noted in the other PR, GFM actually supports double spaces as line breaks (https://github.github.com/gfm/#hard-line-breaks), who knew!

This uses the other option of \ to indicate a line break so editors don't automatically clean it up and cause issues in the future

Hi, I noticed that the links to useSuspenseQuery and useFragment weren't linking to the proper place. It looks like those hooks got moved out of experimental and are stable now. I updated those links. Looks like my editor also cleared out some trailing whitespace, hopefully that is okay.

Resolves #1552

Behavior

Before the change?

• Environments API did not exist (https://docs.github.com/en/rest/deployments/environments)

After the change?

• Environments API is implemented

Other information

Additional info

Pull request checklist

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
• Added the appropriate label for the given change

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes (Please add the Type: Breaking change label)
• No

If Yes, what's the impact:

• N/A

Pull request type

Please add the corresponding label for change this PR introduces:

• Bugfix: Type: Bug
• Feature/model/API additions: Type: Feature
• Updates to docs or samples: Type: Documentation
• Dependencies/code cleanup: Type: Maintenance

Ran rails app:update seemed to resolve the CORS issues I was running into