[fpc-pascal] Troubles with SQLDBRESTBridge

[Michael Van Canneyt]

On Sun, 23 Jun 2019, Sven Barth via fpc-pascal wrote:

>>> Okay, independently of whether the REST module is the optimal 
>>> solution or not, it should work, right? (and shouldn't the Wiki entry 
>>> then mention the advantages/disadvantages of the two approaches? 
>>> Cause when looking at the SQLDB REST module I thought "yay, less 
>>> stuff to configure" and rolled with that)
>>
>> What exactly is less to configure ? :)
>
> Looking at the Wiki again I was fooled by the Datamodule having 8 bullet 
> points, the SQLDBRestModule having 5, but the later simply shortening 
> stuff with point five... So yeah... not really less to configure... My 
> fault. ^^'

It's OK. I will try to document it a little better.

>>> Cause with the changes you committed the example provided with 
>>> Lazarus still does not work (even if I change MyDispatcher.Active to 
>>> False and MyDispatcher.BasePath to 'REST'). The error is always 
>>> "INVALID RESOURCE" which means that ExtractRestResourceName returned 
>>> an empty string (which is logical, cause there neither exists a route 
>>> that sets 'resource' nor is HandleMetadataRequest ever called).
>>>
>>
>> Ah. Documentation issue.
>> If you use a restmodule, then I expect the resource to be provided using
>> ?resourceParam=Name, not in the URL.
>>
>> See
>> function TSQLDBRestDispatcher.ExtractRestResourceName(IO: TRestIO): 
>> UTF8String;
>
> Ah! But that isn't mentioned in the Wiki, right? Cause the Wiki only 
> mentioned the URL based stuff and thus I assumed the SQLDBRESTModule to 
> behave the same...

Well, ideally it would be so, and I think I have a way to do it without
additional options: the module can simply set the routing params before
calling HandleRequest.


> By the way: I sometimes get a EStreamError *after* all data had been 
> sent to the client. I have not yet found a reproducible way for this...

Please make sure  you have the latest version of everything: I had this a
couple of times in case of an error. I fixed all occurrences, I hope.

But if you find additional cases: let me know.

>
>>
>> We can of course change that to try and look in the URL as well using
>> GetNextPathInfo on the request if the routes are not registered,
>> that should work.
>>
>> But then it needs to be done early on in the HandleRequest because the
>> rdoInConnection needs to be observed, so the path can be read only 
>> once. It will probably require a new rdoUseRequestPathInfo, which 
>> could be set by
>> the restmodule... I will look at this.
>>
>
> Would at least be nice to not have to care how one needs to call the 
> server side...

I agree, see above :)

>
>>> - localhost:8080/metadata works
>>> - localhost:8080/users returns "INVALID RESOURCE"
>>
>> Because it has rdoConnectionInURL set, and so you must do
>> localhost:8080/expenses/users
>
> Ahhhhhh! Hadn't seen that this option is active... Okay, then it indeed 
> works as expected, both with and without rdoConnectionInURL.
>
> By the way: I noticed a slight annoyance, but I don't know whether one 
> can really do something about that: When I set rdoConnectionInURL to 
> False inside the object inspector it turns on again, because 
> rdoConnectionResource is set. Took me a moment to look at the source 
> code to see that I need to disable rdoConnectionResource first. Don't 
> know what a better solution would be...

Funny you mention this, I was fooled myself yesterday, I also had to look in
the sources :(

One way would be to disable rdoConnectionResource if you disable
rdoConnectionInURL. I will add this.

>
> Further thing I noticed when testing BufClient and CSVClient: Changing 
> the resource doesn't work there either. I don't get an exception like 
> with JSONClient, but simply nothing happens.

Strange. I will test the examples again. Thanks for pointing it out !

Michael.