Fix materialized view creation

[csalvato]

This PR fixes an issue with the creation of materialized views in the ClickHouse adapter, specifically addressing the order of SQL clauses and engine specification.

Motivation

When using rails db:schema:load:clickhouse on a fresh DB, materialized views are not created correctly because the schema dumper and loader don't properly handle the full ClickHouse materialized view syntax.

Example of what happens:

1. We create a materialized view in a migration and the schema dumper correctly captures the full SQL in a comment:

CREATE MATERIALIZED VIEW dev.aggregated_meter_events_mv TO dev.aggregated_meter_events ( `meter_id` String, `date` Date, `total_quantity` UInt64, `event_count` UInt64 ) AS SELECT meter_id, created_at AS date, sum(quantity) AS total_quantity, count() AS event_count FROM dev.meter_events GROUP BY meter_id, created_at

3. But when loading the schema, it generates incorrect SQL:

CREATE MATERIALIZED VIEW aggregated_meter_events_mv AS SELECT meter_id, created_at AS date, sum(quantity) AS total_quantity, count() AS event_count FROM dev.meter_events GROUP BY meter_id, created_at

Note, the TO statement is just missing 😲

Changes

1. Restructured the visit_TableDefinition method to properly handle different types of table/view creation:

   • Regular tables with column definitions
   • Materialized views with TO clause
   • Materialized views without TO clause
   • Regular views

2. Fixed the order of SQL clauses for materialized views:

   • For materialized views without a TO clause, the ENGINE clause is now correctly placed before the AS clause
   • Engine is now set to Memory() for materialized views without TO clause
   • Removed engine handling from regular views
   • Simplified table options to only apply to regular tables

3. Improved code organization and readability by:

   • Grouping related operations together
   • Adding clear comments for each section
   • Separating the logic for different types of tables/views

The changes ensure that materialized views are created with the correct SQL syntax, fixing issues where view creation would fail due to incorrect clause ordering. All tests are now passing, including specific tests for materialized view creation and dropping.

Testing

• All 78 existing test examples are passing + added another test for this case.
• Verified proper SQL generation for different view types

These changes make the adapter more robust and reliable when working with ClickHouse materialized views.

[YuLeven]

So it stores this in the RAM?

[csalvato]

Yes. If the create_table definition does not include a to value but the view: materialized k/v pair is set so that we need to make a to clauses, we will default to storing the data in memory (since we don't know what tables we can use to store it, and Null() engine wouldn't make sense).

[csalvato]

@PNixx What's the process for reviewing and merging here?