Is your feature request related to a problem? Please describe.
I am using mikro with an underlying postgres db.
Many useful patterns come out-of-the-box with mikro-orm (I'm thinking about caching, identity-map and most importantly, unit-of-works, so transactions and batch reads & inserts). It would also allow ocoda to deal with an ORM layer rather than creating connector for each database type, as I believe mikro supports all the current databases that ocoda supports. Having the events and projections be entities would also enable better relationships between objects and would be a solid addition to the already very nice ocoda feature set.
I also believe that the responsibility for creation tables (ensuring collections exists for instance) would probably be better when managed by a migrator system like mikro-orm's - but that would be opinion rather than fact.
Describe the solution you'd like
A mikro-orm connector.
Describe alternatives you've considered
As ocoda only uses the drivers themselves I'm not quite sure of what the alternatives would be ; besides the current approach of using only the low-level drivers.
Is your feature request related to a problem? Please describe.
I am using mikro with an underlying postgres db.
Many useful patterns come out-of-the-box with mikro-orm (I'm thinking about caching, identity-map and most importantly, unit-of-works, so transactions and batch reads & inserts). It would also allow ocoda to deal with an ORM layer rather than creating connector for each database type, as I believe mikro supports all the current databases that ocoda supports. Having the events and projections be entities would also enable better relationships between objects and would be a solid addition to the already very nice ocoda feature set.
I also believe that the responsibility for creation tables (ensuring collections exists for instance) would probably be better when managed by a migrator system like mikro-orm's - but that would be opinion rather than fact.
Describe the solution you'd like
A mikro-orm connector.
Describe alternatives you've considered
As ocoda only uses the drivers themselves I'm not quite sure of what the alternatives would be ; besides the current approach of using only the low-level drivers.