log-data 1.1.6

All functions that assist in standardising development approaches.

Notes

1. What do I need to worry about?
   1. notion: api key
   2. psql: connecting to the psql database
2. Notion high level page id: b74cbfbe7cc2490e9dc3210f06eb3c8e Workings (as dictated by the package): High level page consist of pages, where those pages is named after the database table the log data is suppose to be stored.

Changes

buggy catcher

• Unable to store data in notion when psql cannot be connected to.
• The app is slowing down significantly ever since the implementation of logging functions.

improvements

• using the inspect.stack() to get the file name, directory name, and function name, rather than writing the name yourself.

Structures

logging functionality setup

graph TD
1[setup notion api key]
2[import logging package]
3[initialise log class]
4[initialise database within log class]
5[know the order of columns_excluding id column and timestamp column]
6[write logs inside specific location in your code based on the order above]

1-->2
2-->3
3-->4
4-->5
5-->6

Process of logging data

graph TD
1[get_the_data]
2[check_if_data_is_string]
3[check_if_data_equal_table_columns]
4[create_the_postgres_command]
5[execute_command]

6[store_log_in_notion]

stat1[main success]
stat2[failure_correct_data]
stat3[failure_wrong_data]
stat4[raise error]
stat5[alternate success]
stat6[absolute failure]

1-->2
2-->3
3-->4
4-->5
5-->stat1
5-->stat2
stat2-->6


2-->stat3
3-->stat3
stat3-->stat4
6-->stat5
6-->stat6
stat6-->stat4

Change log

[1.1.6] - 2024-08-01

add: fixed:

1. store_log method uses a variable called location that does not exist when returning the success message. others:

[1.1.5] - 2024-07-31

add: fixed: others:

1. Removed notion logic from store_log method
2. Checking why app.py for my personal remote server is not logging data (e.g. visual_list_2) when other sub routes are able to (e.g. custom_package_usage/usage)

[1.1.4] - 2024-07-06

add: fixed:

1. custom_logger: In the function called store_log_in_database, Error with command execution produces an output (key) that is not an object, which caused store_log to function to produce an error when the storeLogDatabase produced an error during psql command execution. Made that function's output return an object instead of a string. others:

[1.1.3] - 2024-07-05

add: fixed:

1. Notion: Removed an extract_all_blocks_from_page function execution. It is clogging up the screen with useless information each time I run a program that uses custom packages that has log functions embedded into them. others:

[1.1.3] - 2024-07-01

add: fixed:

1. custom_logger: Logging_table_name is set after connecting to the database. Corrected to set upon instantiation of the class. others:
2. Notion upload operation requires logging_table_name, so that later, it can update the respective table. However, logging_table_name is only set when database connection is successful.

[1.1.2] - 2024-07-01

add:

1. custom_logger: initialise_database, added an operation when operation error is being patched, that involves checking if notion can be accessed. If no, raise an error. If yes, set storage_location to notion. fixed:
2. custom_logger: removed psql client existence checking from store log in notion method as operation involving storing data in notion is not dependent on having a psql connection. others:
3. Removed database redundant function called get_, that handles database query.
4. There is a bug that prevents notion storage when psql cannot be connected to.

[1.1.1] - 2024-06-19

add: fixed: others:

1. Changed initialising method. Instead of explicitly putting database name and table name, get it from the environment variable.

[1.1.0] - 2024-06-20

add:

1. Utility: Created get_package_name function. Auto seeking of file name, package name, and function name, using inspect.stack(). fixed:
2. the error arising from logging applied to a package that is used by logging. To solve it (see 2 and 3 below in fixed)
3. Brought over page operations from personalNotion into notion file
4. Embedded manual psql operations in custom_logging file others:

[1.0.2] - 2024-06-19

add:

1. store_log_in_database gets a new error condition, involving client being None. No client, no database access. fixed: others:
2. Rearrange creation of foundation class instance (personalDatabase package) to be during initialising_database function operation rather than on initialising an instance of custom_logger class. Attempting to solve the "does not exist problem" for foundation class during usage of the package that uses custom_logger.

[1.0.1] - 2024-06-19

add: fixed:

1. Possibility of infinite loop as log function depends on database functions and notion functions, which are going to be logged. Therefore, a state variable called logging_in_progress is created, and checked by log_data at the beginning, change if false, return if true, and change to false after completion or before raising an error. others:
2. Applying trial operation, meant to handle perceive risk involving infinite loop due to two functions depending on one another. database_upload -> log -> database

[1.0.0] - 2024-06-19

add:

1. custom_logger: class to manage all processes of storing data in the database
2. custom_logger: change_storage_location function
3. custom_logger: initialise_database. Set the configuration for connecting to database. Uses personalDatabase package.
4. custom_logger: get_date_time. Returns the current date time object
5. custom_logger: store_log. looks at storage location variable, outcome of database storage attempt, to decide if storing log data in notion is necessary.
6. store_log in notion: store log in notion
7. store_log_in_database: store log in database fixed: others:
8. Core components: psql, notion
9. Mechanics between components: psql is where you store the data. If psql is not accessible, then store in notion.
10. data characteristic that determines whether log data can be stored: a string, number of values separated by commas is equal to number of columns in the table (excluding id and timestamp)