Multiple service submodules in ServiceBuilder module

[Norbert Gyurian, modificado 6 Anos atrás.]

Hi everyone,
here is my problem: i have multiple databases (test, development, etc.) with the SAME tables. I would like to have a combobox in a portlet to change the database to read from.
Is it possible to have multiple service submodules (to have different database connections) in ServiceBuilder module? These service submodules would use the same API module (i have equal tables in these databases)? Or do you have a better solution? I would appreciate some help.

[David H Nebinger, modificado 6 Anos atrás.]

So you cannot use different modules with the same classes, so the module idea is going to be hard to pull off. Additionally, as you pointed out, a SB module can only point to a single DB and does not support switching.

I don't believe this is going to be possible.










Come meet me at the 2017 LSNA!

[Noro G, modificado 6 Anos atrás.]

Thank you for your answer. What would you do in my place? Do I have to write my own data access layer?

[David H Nebinger, modificado 6 Anos atrás.]

Not knowing what you're doing, it's hard to answer.

Many organizations, for example, do not allow the non-production environments to access the production database, and often the environments are not allowed to cross each other at all, so what you're asking doesn't make sense.

So a lot depends upon how, exactly, you plan to do all of this. Will all environments have all access to all databases? If not, this may not be worth the time and effort trying to resolve. Burning cycles creating stuff only for lower layers of your infrastructure will often be questioned by management; they want to see ROI and there just isn't any for dev tools.

All politics aside, I would likely solve this by creating separate Service Builder projects for each environment. But I would also add another environment using Fake Entities: https://web.liferay.com/web/user.26526/blog/-/blogs/fake-servicebuilder-entities.

The fake entities become your facade, and it would be responsible for choosing which of the actual service layers to proxy to and would need to marshal pojos back and forth.

Your "db selector" thing would need to be captured and passed as an argument to the facade layer, either directly or perhaps indirectly in a ServiceContext.

There are still tons of issues around all of this, however. How do you handle indexing and searching? Caching you'd want to disable at the facade level, but how about at the service level?







Come meet me at the 2017 LSNA!