Added schema field to OrmarConfig

[hk3dva]

Added use of schema in foreign keys, Many to Many
Added field to schema conversion via sqlalchemy

[MaximSrour]

Definitely do not commit a .env file.

If you need to rely on a .env file, create a template (e.g., .env.example) and add .env into the gitignore.

It would also require some form of documentation in the README to explain the purpose of this.

[hk3dva]

Thanks for the note, I didn’t notice that the original project did not have a preset ignoring env files

[hk3dva]

For me personally, this functionality is necessary to build a system built for data analysis in a company. I have many different users who have their own schemes with their own rights. I would like to give them access only to their schemas, without generating configs for each of them
I also saw the issues in discussions about schema support, but no one promoted it

[codspeed-hq]

Merging this PR will degrade performance by 28.35%

⚡ 4 improved benchmarks
❌ 7 regressed benchmarks
✅ 73 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
⚡	test_get_one[1000]	4.7 ms	3.4 ms	+38.62%
❌	test_avg[1000]	3.9 ms	4.6 ms	-15.22%
❌	test_max[500]	2.8 ms	3.5 ms	-21.61%
❌	test_get_or_none[1000]	4 ms	4.8 ms	-16.55%
⚡	test_avg[500]	3.5 ms	2.9 ms	+20.3%
⚡	test_min[1000]	4.5 ms	4 ms	+13.85%
❌	test_sum[1000]	3.5 ms	4.9 ms	-28.35%
❌	test_min[500]	3 ms	3.5 ms	-15.58%
❌	test_making_and_inserting_models_in_bulk[10]	4.2 ms	5.3 ms	-21.07%
⚡	test_get_or_create_when_get[500]	3.6 ms	2.5 ms	+44.95%
❌	test_exists[1000]	4.1 ms	4.8 ms	-13.56%

---

_{Comparing hk3dva:feature_add_schema_to_ormar_config (0f91b4b) with master (aec3b5d)}

[collerek]

Hi, looks promising but I'm missing some more query-related tests -> there is quite a complicated table and column prefixing happening under the hood to prevent colliding on the same names between tables and columns.

That's why we need to test some joins -> like select related, prefetch related, same table joins, multiple joins to the same table, accessing relationships and reverse relationships from models, and some filtering.

Between the tables in different schemas as same table schema is covered, probably also some joins to the 2 tables with same name but in different schemas. I know that it's most common use case is separation and not combining data in different schemas, but with proper permissions, that is a perfectly valid use case, so we need to make sure it works as expected.