[fpc-pascal] Troubles with SQLDBRESTBridge

[Sven Barth]

Am 23.06.2019 um 00:50 schrieb Michael Van Canneyt:
>
>
> On Sat, 22 Jun 2019, Sven Barth via fpc-pascal wrote:
>
>>> The REst Module has the additional disadvantage that you must have an
>>> initial /REST/ or whatever part in your URL. With the dispatcher on a
>>> datamodule, you can skip this if so desired...
>>
>> 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. ^^'

>
>>
>> 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...

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...

>
> 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...

>> - 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...

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.

Regards,
Sven