You are not logged in.
Pages: 1
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
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
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
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!
Hope it helps.
Offline
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
Offline
As usual you are right. Must have been a compiler glitch ... :s
Offline
Pages: 1