#[cfg(feature = "mssql")]

pub extern crate async_std;

pub extern crate futures;

pub extern crate lazy_static;

#[cfg(feature = "mysql")]

pub extern crate mysql_async;

#[cfg(feature = "mssql")]

pub extern crate tiberius;

pub extern crate tokio;

#[cfg(feature = "postgres")]

pub extern crate tokio_postgres;

pub extern crate tokio_util;

pub mod canyon_database_connector;

pub mod datasources;

use std::fs;

use std::path::PathBuf;

use crate::datasources::{CanyonSqlConfig, DatasourceConfig};

use canyon_database_connector::DatabaseConnection;

use indexmap::IndexMap;

use lazy_static::lazy_static;

use tokio::sync::{Mutex, MutexGuard};

use walkdir::WalkDir;

lazy_static! {

    pub static ref CANYON_TOKIO_RUNTIME: tokio::runtime::Runtime =

        tokio::runtime::Runtime::new()  // TODO Make the config with the builder

            .expect("Failed initializing the Canyon-SQL Tokio Runtime");

    static ref RAW_CONFIG_FILE: String = fs::read_to_string(find_canyon_config_file())

        .expect("Error opening or reading the Canyon configuration file");

    static ref CONFIG_FILE: CanyonSqlConfig = toml::from_str(RAW_CONFIG_FILE.as_str())

        .expect("Error generating the configuration for Canyon-SQL");

    pub static ref DATASOURCES: Vec<DatasourceConfig> =

        CONFIG_FILE.canyon_sql.datasources.clone();

    pub static ref CACHED_DATABASE_CONN: Mutex<IndexMap<&'static str, DatabaseConnection>> =

        Mutex::new(IndexMap::new());

}

        .max_depth(2)

        .into_iter()

    {

        {

        }

/// Convenient free function to initialize a kind of connection pool based on the datasources present defined

/// in the configuration file.

///

/// This avoids Canyon to create a new connection to the database on every query, potentially avoiding bottlenecks

/// coming from the instantiation of that new conn every time.

///

/// Note: We noticed with the integration tests that the [`tokio_postgres`] crate (PostgreSQL) is able to work in an async environment

/// with a new connection per query without no problem, but the [`tiberius`] crate (MSSQL) suffers a lot when it has continuous

/// statements with multiple queries, like and insert followed by a find by id to check if the insert query has done its

/// job done.

                        "Error pooling a new connection for the datasource: {:?}",

                        datasource.name

                    )

                }),

    }

///

    datasource_name: &str,

    guarded_cache: &'a mut MutexGuard<IndexMap<&str, DatabaseConnection>>,

) -> &'a mut DatabaseConnection {

            .get_mut(

                    .get(0)

                    .expect("We didn't found any valid datasource configuration. Check your `canyon.toml` file")

                    .name

                    .as_str()

    } else {

            )

    }

    datasource_name: &str,

    datasources_config: &'a [DatasourceConfig],

) -> &'a DatasourceConfig {

            .get(0)

    } else {

            .iter()

    }