Consinstent naming for TableMock

Author: Somtom

docsource/faq.md

@@ -5,13 +5,13 @@
 
 We are planning to add more and more supported database systems. However, if your system is not supported yet, you can still use SQL Mock. There are only 2 things you need to do:
 
-### Create your `MockTable` class
+### Create your `TableMock` class
 
-First, you need to create a `MockTable` class for your database system that inherits from `sql_mock.table_mocks.BaseMockTable`.
+First, you need to create a `TableMock` class for your database system that inherits from `sql_mock.table_mocks.BaseTableMock`.
 
 That class needs to implement the `_get_results` method which should make sure to fetch the results of a query (e.g. produced by `self._generate_query()`) and return it as list of dictionaries.
 
-Look at one of the existing client libraries to see how this could work (e.g. [BigQueryMockTable](https://github.com/DeepLcom/sql-mock/blob/main/src/sql_mock/bigquery/table_mocks.py)).
+Look at one of the existing client libraries to see how this could work (e.g. [BigQueryTableMock](https://github.com/DeepLcom/sql-mock/blob/main/src/sql_mock/bigquery/table_mocks.py)).
 
 You might want to create a settings class as well in case you need some specific connection settings to be available within the `_get_results` method.
 
@@ -41,7 +41,6 @@ class String(MyFanceDatabaseColumnMock):
 There will definitely be folks in the community that are in the need of support for the database you just created all the setup for.
 Feel free to create a PR on this repository that we can start supporting your database system!
 
-
 ## I am missing a specific ColumnMock type for my model fields
 
 We implemented some basic column types but it could happen that you don't find the one you need.

docsource/getting_started/quickstart.md

@@ -6,15 +6,15 @@
 
 Before diving into specific database scenarios, let's start with a simplified example of how SQL Mock works behind the scenes.
 
-
 1. You have an original SQL query, for instance:
+
    ```sql
    -- path/to/query_for_result_table.sql
    SELECT id FROM data.table1
    ```
 
+2. Using SQL Mock, you define mock tables. You can use the built-in column types provided by SQL Mock. Available column types include `Int`, `String`, `Date`, and more. Each database type has their own column types. Define your tables by subclassing a mock table class that fits your database (e.g. `BigQueryTableMock`) and specifying the column types along with default values. In our example we use the `ClickHouseTableMock` class
 
-2. Using SQL Mock, you define mock tables. You can use the built-in column types provided by SQL Mock. Available column types include `Int`, `String`, `Date`, and more. Each database type has their own column types. Define your tables by subclassing a mock table class that fits your database (e.g. `BigQueryMockTable`) and specifying the column types along with default values. In our example we use the `ClickHouseTableMock` class
     ```python
     from sql_mock.clickhouse import column_mocks as col
     from sql_mock.clickhouse.table_mocks import ClickHouseTableMock
@@ -24,13 +24,14 @@ Before diving into specific database scenarios, let's start with a simplified ex
     class Table(ClickHouseTableMock):
         id = col.Int(default=1)
         name = col.String(default='Peter')
-    
+
     @table_meta(table_ref='data.result_table', query_path='path/to/query_for_result_table.sql')
     class ResultTable(ClickHouseTableMock):
         id = col.Int(default=1)
     ```
 
 3. **Creating mock data:** Define mock data for your tables using dictionaries. Each dictionary represents a row in the table, with keys corresponding to column names. Table column keys that don't get a value will use the default.
+
     ```python
     user_data = [
         {}, # This will use the defaults for both id and name
@@ -41,40 +42,42 @@ Before diving into specific database scenarios, let's start with a simplified ex
     input_table_mock = Table.from_dicts(user_data)
     ```
 
-
 4. **Getting results for a table mock:** Use the `from_mocks` method of the table mock object to generate mock query results based on your mock data.
+
     ```python
     res = ResultTable.from_mocks(input_data=[input_table_mock])
     ```
 
 5. Behind the scene SQL Mock replaces table references (e.g. `data.table1`) in your query with Common Table Expressions (CTEs) filled with dummy data. It can roughly be compared to something like this:
+
     ```sql
     WITH data__table1 AS (
         -- Mocked inputs
-        SELECT 
-            cast('1' AS 'String') AS id, 
+        SELECT
+            cast('1' AS 'String') AS id,
             cast('Peter' AS 'String') AS name
-        UNION ALL 
-        SELECT 
-            cast('2' AS 'String') AS id, 
+        UNION ALL
+        SELECT
+            cast('2' AS 'String') AS id,
             cast('Martin' AS 'String') AS name
-        UNION ALL 
-        SELECT 
-            cast('3' AS 'String') AS id, 
+        UNION ALL
+        SELECT
+            cast('3' AS 'String') AS id,
             cast('Peter' AS 'String') AS name
     )
 
     result AS (
         -- Original query with replaced references
-        SELECT id FROM data__table1 
+        SELECT id FROM data__table1
     )
 
-    SELECT 
+    SELECT
         cast(id AS 'String') AS id
     FROM result
     ```
 
 6. Finally, you can compare your results to some expected results using the `assert_equal` method.
+
     ```python
     expected = [{'id': '1'},{'id': '2'},{'id': '3'}]
     res.assert_equal(expected)

docsource/usage/bigquery/examples.md

@@ -7,26 +7,26 @@
 ```python
 import datetime
 from sql_mock.bigquery import column_mocks as col
-from sql_mock.bigquery.table_mocks import BigQueryMockTable
+from sql_mock.bigquery.table_mocks import BigQueryTableMock
 from sql_mock.table_mocks import table_meta
 
-# Define mock tables for your data model that inherit from BigQueryMockTable
+# Define mock tables for your data model that inherit from BigQueryTableMock
 @table_meta(table_ref='data.users')
-class UserTable(BigQueryMockTable):
+class UserTable(BigQueryTableMock):
     user_id = col.Int(default=1)
     user_name = col.String(default='Mr. T')
 
 
 @table_meta(table_ref='data.subscriptions')
-class SubscriptionTable(BigQueryMockTable):
+class SubscriptionTable(BigQueryTableMock):
     subscription_id = col.Int(default=1)
     period_start_date = col.Date(default=datetime.date(2023, 9, 5))
     period_end_date = col.Date(default=datetime.date(2023, 9, 5))
     user_id = col.Int(default=1)
 
 
 # Define a mock table for your expected results
-class SubscriptionCountTable(BigQueryMockTable):
+class SubscriptionCountTable(BigQueryTableMock):
     subscription_count = col.Int(default=1)
     user_id = col.Int(default=1)
 
@@ -50,13 +50,13 @@ subscriptions = SubscriptionTable.from_dicts([
 
 # Define your expected results
 expected = [
-    {'user_id': 1, 'subscription_count': 2}, 
+    {'user_id': 1, 'subscription_count': 2},
     {'user_id': 2, 'subscription_count': 1}
 ]
 
 # Simulate the SQL query using SQL Mock
 res = SubscriptionCountTable.from_mocks(
-    query=query, 
+    query=query,
     input_data=[users, subscriptions]
 )
 

docsource/usage/dbt.md

@@ -31,10 +31,10 @@ For dbt models, use the `dbt_model_meta` decorator from `sql_mock.dbt`. This dec
 
 ```python
 from sql_mock.dbt import dbt_model_meta
-from sql_mock.bigquery.table_mocks import BigQueryMockTable
+from sql_mock.bigquery.table_mocks import BigQueryTableMock
 
 @dbt_model_meta(model_name="your_dbt_model_name")
-class YourDBTModelTable(BigQueryMockTable):
+class YourDBTModelTable(BigQueryTableMock):
     # Define your table columns and other necessary attributes here
     ...
 ```
@@ -45,10 +45,10 @@ For dbt sources, use the `dbt_source_meta` decorator from `sql_mock.dbt`. This i
 
 ```python
 from sql_mock.dbt import dbt_source_meta
-from sql_mock.bigquery.table_mocks import BigQueryMockTable
+from sql_mock.bigquery.table_mocks import BigQueryTableMock
 
 @dbt_source_meta(source_name="your_source_name", table_name="your_source_table")
-class YourDBTSourceTable(BigQueryMockTable):
+class YourDBTSourceTable(BigQueryTableMock):
     # Define your table columns and other necessary attributes here
     ...
 ```
@@ -59,10 +59,10 @@ For dbt seeds, which are static data sets loaded into the database, use the `dbt
 
 ```python
 from sql_mock.dbt import dbt_seed_meta
-from sql_mock.bigquery.table_mocks import BigQueryMockTable
+from sql_mock.bigquery.table_mocks import BigQueryTableMock
 
 @dbt_seed_meta(seed_name="your_dbt_seed_name")
-class YourDBTSeedTable(BigQueryMockTable):
+class YourDBTSeedTable(BigQueryTableMock):
     # Define your table columns and other necessary attributes here
     ...
 ```
@@ -75,14 +75,14 @@ Let’s consider a dbt model named `monthly_user_spend` that aggregates data fro
 
 ```python
 @dbt_source_meta(source_name="transactions", table_name="user_transactions")
-class UserTransactionsTable(BigQueryMockTable):
+class UserTransactionsTable(BigQueryTableMock):
     transaction_id = col.Int(default=1)
     user_id = col.Int(default=1)
     amount = col.Float(default=1.0)
     transaction_date = col.Date(default='2023-12-24')
 
 @dbt_seed_meta(seed_name="user_categories")
-class UserCategoriesTable(BigQueryMockTable):
+class UserCategoriesTable(BigQueryTableMock):
     user_id = col.Int(default=1)
     category = col.String(default='foo')
 ```
@@ -91,7 +91,7 @@ class UserCategoriesTable(BigQueryMockTable):
 
 ```python
 @dbt_model_meta(model_name="monthly_user_spend")
-class MonthlyUserSpendTable(BigQueryMockTable):
+class MonthlyUserSpendTable(BigQueryTableMock):
     user_id = col.Int(default=1)
     month = col.String(default='foo')
     total_spend = col.Float(default=1.0)

docsource/usage/default_values.md

@@ -6,17 +6,17 @@
 
 Testing SQL queries can often involve repetitive setup for mock tables. In SQLMock, one effective way to streamline this process is by using default values. By setting reasonable defaults, you can significantly reduce the boilerplate code in your tests, especially when dealing with multiple input tables or complex queries. Let’s explore how you can efficiently implement this.
 
-## Utilizing Default Values in MockTable Fields
+## Utilizing Default Values in TableMock Fields
 
 Defining default values at the field level in your mock tables is straightforward.
-The default argument in the field definition allows you to set default values consistency across all test scenarios in one step. 
+The default argument in the field definition allows you to set default values consistency across all test scenarios in one step.
 They are particularly useful for ensuring that joins and other query functionalities operate correctly.
 
 Here's an example:
 
-```python 
+```python
 @table_meta(table_ref="data.users")
-class UserTable(BigQueryMockTable):
+class UserTable(BigQueryTableMock):
     user_id = col.Int(default=1)
     user_name = col.String(default="Mr. T")
 
@@ -30,23 +30,22 @@ users = UserTable.from_dicts([
 
 ## Setting Mock Defaults with table_meta
 
-
-When defining your MockTable classes, the `table_meta` decorator accepts a `default_inputs` argument.
+When defining your TableMock classes, the `table_meta` decorator accepts a `default_inputs` argument.
 The Mock instances passed here, will be used as defaults in the `from_mocks` method.
 
 Consider this example:
 
-```python 
+```python
 @table_meta(
     query_path="./examples/test_query.sql",
     default_inputs=[UserTable([]), SubscriptionTable([])] # We can provide defaults for the class if needed.
 )
-class MultipleSubscriptionUsersTable(BigQueryMockTable):
+class MultipleSubscriptionUsersTable(BigQueryTableMock):
     user_id = col.Int(default=1)
 
 # Setting up different scenarios to demonstrate the use of defaults
 users = UserTable.from_dicts([
-    {"user_id": 1}, 
+    {"user_id": 1},
     {"user_id": 2}
 ])
 subscriptions = SubscriptionTable.from_dicts(

docsource/usage/defining_table_mocks.md

@@ -4,28 +4,28 @@
 
 # Defining table mocks
 
-When you want to provide mocked data to test your SQL model, you need to create MockTable classes for all upstream data that your model uses, as well as for the model you want to test. Those mock tables can be created by inheriting from a `BaseMockTable` class for the database provider you are using (e.g. `BigQueryMockTable`).
+When you want to provide mocked data to test your SQL model, you need to create TableMock classes for all upstream data that your model uses, as well as for the model you want to test. Those mock tables can be created by inheriting from a `BaseTableMock` class for the database provider you are using (e.g. `BigQueryTableMock`).
 
 **We recommend to have a central `model.py` file where you create those models that you can easily reuse them across your tests**
 
 ```python
 # models.py
 
 from sql_mock.bigquery import column_mocks as col
-from sql_mock.bigquery.table_mocks import BigQueryMockTable, table_meta
+from sql_mock.bigquery.table_mocks import BigQueryTableMock, table_meta
 
 # The models you are goign to use as inputs need to have a `table_ref` specified
 @table_meta(table_ref='data.table1')
-class Table(BigQueryMockTable):
+class Table(BigQueryTableMock):
     id = col.Int(default=1)
     name = col.String(default='Peter')
 
 @table_meta(
-    table_ref='data.result_table', 
-    query_path='path/to/query_for_result_table.sql', 
+    table_ref='data.result_table',
+    query_path='path/to/query_for_result_table.sql',
     default_inputs=[Table()] # You can provide default inputs on a class level
 )
-class ResultTable(BigQueryMockTable):
+class ResultTable(BigQueryTableMock):
     id = col.Int(default=1)
 ```
 
@@ -34,16 +34,19 @@ Some important things to mention:
 **The models you are goign to use as inputs need to have a `table_ref` specified.**
 The `table_ref` is how the table will be referenced in your production database (usually some pattern like `<schema>.<table>`)
 
-**The result model needs to have a query.** 
-There are currently 2 ways to provide a query to the model: 
+**The result model needs to have a query.**
+There are currently 2 ways to provide a query to the model:
+
+1. Pass a path to your query file in the class definition using the `table_meta` decorator. This allows us to only specify it once.
 
-1. Pass a path to your query file in the class definition using the `table_meta` decorator. This allows us to only specify it once.   
     ```python
     @table_meta(table_ref='data.result_table', query_path='path/to/query_for_result_table.sql')
-    class ResultTable(BigQueryMockTable):
+    class ResultTable(BigQueryTableMock):
         ...
     ```
+
 2. Pass it as `query` argument to the `from_mocks` method when you are using the model in your test. This will also overwrite whatever query was read from the `query_path` in the `table_meta` decorator.
+
     ```python
     res = ResultTable.from_mocks(query='SELECT 1', input_data=[<your-input-mocks-table-instances>])
     ```

docsource/usage/redshift/examples.md

@@ -7,25 +7,25 @@
 ```python
 import datetime
 from sql_mock.redshift import column_mocks as col
-from sql_mock.redshift.table_mocks import RedshiftMockTable
+from sql_mock.redshift.table_mocks import RedshiftTableMock
 from sql_mock.table_mocks import table_meta
 
-# Define mock tables for your data model that inherit from RedshiftMockTable
+# Define mock tables for your data model that inherit from RedshiftTableMock
 @table_meta(table_ref="data.users")
-class UserTable(RedshiftMockTable):
+class UserTable(RedshiftTableMock):
     user_id = col.INTEGER(default=1)
     user_name = col.VARCHAR(default="Mr. T")
 
 
 @table_meta(table_ref="data.subscriptions")
-class SubscriptionTable(RedshiftMockTable):
+class SubscriptionTable(RedshiftTableMock):
     subscription_id = col.INTEGER(default=1)
     period_start_date = col.DATE(default=datetime.date(2023, 9, 5))
     period_end_date = col.DATE(default=datetime.date(2023, 9, 5))
     user_id = col.INTEGER(default=1)
 
 # Define a mock table for your expected results
-class SubscriptionCountTable(RedshiftMockTable):
+class SubscriptionCountTable(RedshiftTableMock):
     subscription_count = col.INTEGER(default=1)
     user_id = col.INTEGER(default=1)