persistenceMapperMultiDb

CapableObjects Forums SupportForum persistenceMapperMultiDb

This topic contains 3 replies, has 3 voices, and was last updated by  Peter Buchmann 5 days, 15 hours ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #4594

    william
    Participant

    Hi, I have a need to build some small applications on top of a legacy system (MS SQL) which I can only have read access. I am thinking of using persistenceMapperMultiDb together with a new Eco model (newModel) + reversed engineered model from the legacy system (oldModel). I have created newModel with oldModel being added as reference but cannot find any way to generate the schema to a new MS SQL database. I would like to have the new data created as the new schema (new classes only) and reading the existing data from the legacy database (read only). Does anyone have any experience with multidb usage with MDriven?

    #4605

    Admin
    Keymaster

    Hi William,
    The MultiDB is not not really maintained anymore since there are so many limitations on forcing two databases from 1 ecospace.

    In your case where one db is readonly it might work – but when all dbs are read write the 2-phase-commit and transaction broking made it hard.

    Without knowing anything about volumes here I would consider copying the data (hourly,daily or on change) from legacy to new db – and let the new db be owned by MDriven. Then you will have a complete model where you avoid to change certain classes in it since it is reference data.

    If copying is not an option one may consider doing views in the new database that reads from legacy. If these views can be made to to appear the same as the tables MDriven expects it would be a tight readonly integration.

    #4606

    william
    Participant

    Thanks for your advice. In my case I think I would create 2 separate ecoSpace since the data needed to be shared is really small… BTW, I wonder if MDriven could be used on a .NET Core project in future?

    #4622

    Peter Buchmann
    Participant

    I’ve also experimented with a PersistenceMapperMultiDb some years ago. The findings were exactly as Hans wrote.

    Our solution finally was to develop an EcoSpaceCollection EcoService. This EcoService is registered into an EcoSpace like any other EcoService and can store as many other EcoSpaces as you want. So we only need to pass the main EcoSpace as a parameter and the other EcoSpaces are contained as sub EcoSpaces within the main EcoSpace.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.

Comments are closed.