#1 2013-04-02 11:43:39

h.hasenack
Member
From: Nijmegen, Netherlands
Registered: 2012-08-01
Posts: 173
Website

TSQLRestServer.ExportServer question

Hi Arnaud

For the sake of debugging, and maybe for eleasing too I have been experimenting a little with the embedded (DLL) server solution using runtime packages, and it appears to work just fine.
Well, this is as long as you have only one rest server in your process, it does.

In my case, my 'root' rest server allows for the dynamic creation of 'workbase' rest servers. The problem is that these 'workbase' rest servers cannot export themselves because of the GlobalURIRequestServer variable that is alreaddy occupied by the 'root' rest server.

so... I managed to create and test a runtime, embedded link to my root server, but fail to create a runtime, embedded link to my dynamically created 'workbase' rest servers.

How to I get around this the Mormot way (Currently I'm trying to work around the problem by querying an internal list of restservers)

Maybe we need a TSQLRestCLientURIDirect with constructor Create(aModel:TSQLMode;aServerInstance:TSQLRestServer) for this?


Regards,

Hans

Last edited by h.hasenack (2013-04-02 11:51:55)

Offline

#2 2013-04-02 12:03:54

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,552
Website

Re: TSQLRestServer.ExportServer question

Why not just use TSQLRestServer as a TSQLRest abstract instance?
Since you are on the server side, it could make sense to access directly the TSQLRestServer instances, as you do.
It is not so "shocking", from the mORMot point of view, IMHO.

Perhaps the easier "pure TSQLRestClientURI" implementation may be with a new overloaded constructor for the TSQLRestClientDB class.

Offline

#3 2013-04-02 12:26:49

h.hasenack
Member
From: Nijmegen, Netherlands
Registered: 2012-08-01
Posts: 173
Website

Re: TSQLRestServer.ExportServer question

Yes, , the latter solution would be fine. This allows my tests to derive from each other (using a FRestCLient:TSQLRestClientURI field) in order to test the different 'connection modes' by just overloading the 'InitRestCLient' procedure, which currently looks something like this:

procedure TLCSServerMessageTest.InitRestClient(VAR aSQLRestClient: TSQLRestClientURI;aModel:TSQLModel);
begin
  inherited;
  aSQLRestClient:=TSQLRestClientURIMessage.Create(aModel,aModel.Root,aModel.ClassName+NewGUIDString,1000);
end;
...
procedure TLCSServerNamedPipeTest.InitRestClient(VAR aSQLRestClient: TSQLRestClientURI;aModel:TSQLModel);
begin
  inherited;
  aSQLRestClient:=TSQLRestClientURINamedPipe.Create(aModel,aModel.Root);
end;
....
procedure TLCSServerEmbeddedTest.InitRestClient(VAR aSQLRestClient: TSQLRestClientURI;aModel:TSQLModel);
begin
  inherited;
  aSQLRestClient:=TSQLRestClientURIDll.Create(aModel,@Mormot.URIRequest);
end;
...

and would maybe get to looking like this

....
procedure TLCSServerEmbeddedTest.InitRestClient(VAR aSQLRestClient: TSQLRestClientURI;aModel:TSQLModel);
begin
  inherited;
  aSQLRestClient:=TSQLRestClientURIDirect.Create(aModel,MySQLRestServerInstance);
end;
...

Which allows me to resolve the MySQLRestServerInstance any way I like...

Hans

Offline

#4 2013-04-02 14:10:51

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,552
Website

Re: TSQLRestServer.ExportServer question

A new constructor TSQLRestClientDB.Create(aRunningServer) has been introduced for direct access to an existing TSQLRestServerDB instance.
See http://synopse.info/fossil/info/c5824d2abb

The Model will be cloned from the server one.

No regression tests have been written for this constructor - so feedback is welcome!
smile

Hope it helps.

Offline

#5 2013-04-09 09:10:54

h.hasenack
Member
From: Nijmegen, Netherlands
Registered: 2012-08-01
Posts: 173
Website

Re: TSQLRestServer.ExportServer question

Hi Arnaud

I am trying to use your solution, but I run into the problem that TSQLRestCLient base class (I have to use this one as TSQLRestCLientURI is derived TSQLRestCLient rather than TSQLRestCLientDB) does not have a SetUser method nor a ServiceRegister method. I am now working around it using an "Is TSQLrestCLientURI" test, but It would be nice to have something like a "TSQLRestCLientURIDirect " class, derived from TSQLRestCLientURI that encapsulates this, as aparallel to the TSQLRestCLientURIDLL class.

I have been testing with it as it is, and seems that everyting works as expected upto now.

UPDATE: You may want to consider adding the Batch* routines as virtual/abstract routines to the TSQLRestCLient class. I had to create quite a big workaround for this in my unit tests :s

Regards - Hans

Last edited by h.hasenack (2013-04-09 09:54:31)

Offline

#6 2013-04-09 11:18:11

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,552
Website

Re: TSQLRestServer.ExportServer question

I do not fully understand the point, here.
TSQLRestClientDB inherits from TSQLRestClientURI, so you should be able to use TSQLRestClientURI everywhere instead of TSQLRestClient.

Offline

#7 2013-04-09 11:44:04

h.hasenack
Member
From: Nijmegen, Netherlands
Registered: 2012-08-01
Posts: 173
Website

Re: TSQLRestServer.ExportServer question

As usual you are right. Must have been a compiler glitch ... :s

Offline

Board footer

Powered by FluxBB