Currently the dmxDatabase.php file only looks at public schema which can be changed to show all schemas contents. But the queries generated by the framework does not include the schema name.
While one can change the search_path within Postgres, this does not work if there tables with the same name across multiple schemas. <- which is the case for a project.
So the question is, is there a way to use multiple schemas, or can i change something that adds the schema name to the table name when the metadata is refreshed?
Has more to do with that if it’s something simple to do with the framework, then i can continue with the current setup else i need to switch the objects to the public schema to continue.
The database connector was developed for simple databases normally used on the web. Schemas are not often used unless you have some very complex data structure. I will investigate if it would be possible to easily support schemas within our database connector.
@patrick, with the latest update, which is awesome!, it seems to lent itself for multi schema capabilities. so i was wondering if you had time investigating this besides your busy schedule.
Having multiple schema support is really much more complex - as we have to change all our query builders to allow to first pick the schema picking before getting the tables. While usually you always have a single schema.
Also needing multi-schema support here. Bummer that it doesn’t seem that Wappler team will implement this. Is there another way around this, except having to remodel our entire database structure?
Hi @george I still don’t have the need to use multiple schemas. My only comment was that if possible and if implemented make it so the schema name will accept bindings to make it dynamic.
I can only think of multi-tenancy when speaking about schemas.
I don’t know what non-standard db designs people are using that have this need.
Personally I would like to see by query basis(option 2), but on connection basis would work I guess, just means that one has to make a connection for each schema they want to access.
I do have joins between schemas, but the end result is then pushed to a (martialized) views in public to make it available for Wappler but still keep the majority of the DB design intact.
The reason is because I split-up the modules in the app and also do this in the database. this choice has been made during the design, as it’s not known how big the database will become so wanted to keep it clear and have a more manageable overview in the DB, modules are being made constantly and thus also schemas.
I know that this is not normal practice, but I can see also a way that I would use this as multi tenant style of setup in my environment.