Databroadcast and switchServer

Classic Servoy
1

We have tracked down the (not that obvious) cause of what we see as a bug in the databroadcast with Servoy 5.2.1 (that we found out was already present in the 5.1.x line, maybe comes from before that?)

First let me explain what we do.

We have a few ‘generic’ modules that we use in our solutions, these modules have been developed agains a very simple database.
For example we have a feedback module, which is using a feedback server having one feedback table.

To reuse this module, we simply integrate it into a new solution (checking out from a svn server), then call it’s solutionOpen method from the main solutionOpen method. Of course the module was linked to a database server which is the feedback database server, but now we want all the feedback to be saved into the feedback table of the main server of the solution, lets call it ‘maindb’.
Note that both server have a feedback table with the same structure. But of course the maindb has many more tables…

So what we do is utter a simple call to:

databaseManager.switchServer('feedback', 'maindb');

Which works perfectly well because after that call, the module is now linked to the maindb server and all insertions are made in the feedback table of the maindb server.

But what we found out is that doing so breaks databroadcast completely.
My guess is that internally Servoy is holding a memory map of the schema of the ‘feedback’ table, and tries to apply it to the ‘maindb’ server (which contains many more table), thus when it is time to fire databroadcast, it consults this map again. Since the tables from maindb were not present in the feedback server, it simply ignores them. (Actually not even the feedback table is not firing databroadcast events, but my theory still holds in that since the schema was different, databroadcast is simply broken).

Note that everything else is working perfectly (all inserts/updates/deletes are performed as usual), except that no databroadcast occurs.

We think that what we do is perfectly legal and in our view it is justified by the idea that modules are supposed to be generic and reusable part from one solution to another, thus from one database to another. This is a big problem for us as we have design all our generic modules with that idea in mind.

Please let me know it my understanding of modules is totally wrong or if this behavior is indeed a bug, in which case I will open a report on the support system (not sure how I will provide a sample solution for that though, knowing that the idea is to have 2 datasources, but I can explain this again, and this is reproducible always).

Thanks in advance for your explantations!

2

From what I understand, you created the equivalent of a duplicate server. (like mapping 2 server names to same database jdbc url)
Servoy has indeed a mapping of what is switched server wise…so when a databroadcast comes in its mapped back to only one servername (ignoring the original all together)
To support your programming model, we should have the admin-page ask on solution import, if you want to use another server (like developer does).
Could you please file feature req.?

3

Hi Jan,

not sure what you mean by duplicate server…
Most of my solution is already based on the server to which I’m switching (so maindb in my example).
Only a few modules are using a different servername and are actually switched.

As an admin-page option at solution import is not the same as a scripting option, I’m not sure how this would be useful.
The modules are already linked to my main solution, so already imported in developer (and actually not really imported, but checked out from SVN).

So when you say that the databroadcast is mapped to only one servername ignoring the original, the thing is that for 95% of the tables the original is the same as the new servername! It sounds to me like the new servername is actually the one ignored altogether by databroadcast in my case.

Couldn’t you use the newserver name schema as your map for what would be considered for databroadcast?

4

Well ‘feedback’ and ‘maindb’ point to the same db server, which is the equivalent as a duplicate defined dbserver (for which we warn in servoy developer and application server, exactly for databroadcast reasons)
To support your programming model, the application server solution import should provide the means to map the solution/module from feedback to maindb (the same as eclipse developer solution import does, when a db server is missing).
Then you can keep your module on feedback db server (development time) and no switchServer is needed (at runtime).

5

No! feedback and maindb are two separate database!

Each one has a ‘feedback’ table though.
So I switch from 2 different servers which is what the switchServer is intended to do, isn’t it?

What I’m saying is that if the 2 database don’t have the same schema, databroadcast fails.

6

Yes, they are separate things, but after switchServer from a servoy viewpoint they point to same database!
In other words, you cannot keep using the “destination” server from switchServer function after issuing switchServer …this is what you/your solution does.
switchServer is meant to use in parrallel partioning, like where each customer has its own database, and the solution is told to look to an entire different database (with exactly the same model)…not touching any of original db.
Maybe it would be best if servoy fails when using ‘maindb’ anywhere after issuing databaseManager.switchServer(‘feedback’, ‘maindb’);

7

Hum, I think I get it now! :shock:

What is problematic is that by issuing databaseManager.switchServer(‘feedback’, ‘maindb’);
I’m also doing implicitely databaseManager.switchServer(‘maindb’, ‘maindb’);
because my solution has forms using maindb already.

But in this case maindb being the original servername, it is ignored.

Now what if I create a new maindb2 server (clone of maindb), and did:
databaseManager.switchServer(‘feedback’, ‘maindb2’);
databaseManager.switchServer(‘maindb’, ‘maindb2’);

In my understanding, databroadcast events should be considered for maindb2, am I right?

8

ptalbot:
We have a few ‘generic’ modules that we use in our solutions, these modules have been developed agains a very simple database.
For example we have a feedback module, which is using a feedback server having one feedback table.

To reuse this module, we simply integrate it into a new solution (checking out from a svn server), then call it’s solutionOpen method from the main solutionOpen method. Of course the module was linked to a database server which is the feedback database server, but now we want all the feedback to be saved into the feedback table of the main server of the solution, lets call it ‘maindb’.

You definitely know how to get yourself in trouble :) With that said, we’re still experimenting with the best way to manage the Servoy triage of the resource project, SVN, and modules effectively for re-usability. The interaction of these three pieces when any one of them becomes variable starts making things tricky in a hurry. In your case, you have all three pieces in the variable realm (multiple modules, multiple SVN sources, and multiple resource projects/data).

All of our solutions have 10+ reusable modules. The only way we’re keeping our sanity is by keeping the other two pieces (SVN and resource project) fixed. Which means each entire application we have in production has it’s own SVN and all modules use the same database connections (which we quickly learned to do when Servoy first implemented modules way back). In this scenario we propagate changes to reusable modules to each production SVN server. Usually by exporting a .servoy file, importing into Servoy developer, and then pushing up to that installation’s SVN (which clears up any database connection naming differences as well).

We’ve experimented with putting each reusable module on it’s own SVN server but we haven’t figured out all the resource project implications this would entail yet. Because of the way Servoy implements resource projects, keeping the reusable/common parts of resource projects in sync across multiple SVNs and various multiple module applications is the kicker.

ptalbot:
Now what if I create a new maindb2 server (clone of maindb), and did:
databaseManager.switchServer(‘feedback’, ‘maindb2’);
databaseManager.switchServer(‘maindb’, ‘maindb2’);

In my understanding, databroadcast events should be considered for maindb2, am I right?

Definitely curious if this works. But then how to keep style sheets in sync across all SVNs? Merging at runtime like this seems like a scary hack to me.

9

david:
You definitely know how to get yourself in trouble :)

I like to think out of the box, yes.
As we say in french: “Il faut vivre dangereusement.” - babelfish that! ;)

I just tried:

databaseManager.switchServer('feedback', 'maindb2'); 
databaseManager.switchServer('maindb', 'maindb2');

And databroadcast works for all table that are in maindb except for those who were in feedback.

So I would say that either
1/the data model should strictly match the one of the new server, or
2/you can only switch once, meaning that the first call is then ignored along with all the relevant tables.

10

ptalbot:
As we say in french: “Il faut vivre dangereusement.” - babelfish that! ;)

Nice :)

Another thought I’ve had is to use one SVN server for everything and managing with branches. Each client gets a branch, each of our common modules gets a branch (or the trunk is reserved for them?), etc. Developer workspaces pick what they need from each branch. Purely theoretical musings at this point.