[TinyOWS-dev] About encoding per layer and other things
boolean10001 at yahoo.com
Fri Feb 4 12:46:41 EST 2011
No problem about the delay, I'm quite busy too.
You're right, I forgot to use the ->buf to get the buffer contents as char *,
which I already did on my
linux server when make complained. I'm really sorry to send you the .patch file
It's fine to remove the author comments I made, I just added them as a good
Well, I'll add a new dbEncoding attribute in the general section toset the
client encoding once the
connection is opened to right handling the varchar values in the INSERT/UPDATE
statements within the
The possible values of this attribute will not be validated by TinyOWS and also
it must be include the link
to the PostgreSQL supported encodings
into the TinyOWS documentation.
>WFS-T specification already have a way to handle explicitly locks
>But i didn't implemented them in TinyOWS for now.
>If you have to explore this way, you should also have a look in PostGIS Long
>A patch for WFS-T lock implementation is welcome (since it's strictly conform to
>OGC WFS-T spec)
>But there's some problem IMHO in this OGC lock architecture,as the client have
>to release himself
>each lock he already tooks.(And sometime client will just forget too, or could
>exploit this feature as a
>security hole, kind of quick DoS)
>So GeoServer for instance also provide via administration backoffice,a way for
>administrator to list
>each lock and a way to release them if needed.
>And on the final point, i'm not sure that there's available WFS-T client
>appsable to deal with WFS
It isn't a good idea to allow the client to handle LOCKs. PostgreSQL
automatically detects deadlocks:
PostgreSQL automatically detects deadlock situations and resolves them by
aborting one of the transactions involved, allowing the other(s) to
complete. (Exactly which transaction will be aborted is difficult to
predict and should not be relied upon.)
I will take a look to the PostGIS long transaction features and the OGC WFS-T
There's another failure with the CRS on gvSIG, it just throws an exception while
parsing it, I'll check for that
IC Carlos Ruiz
From: Olivier Courtin <olivier.courtin at gmail.com>
To: TinyOWS developers discuss list <tinyows-dev at lists.maptools.org>
Sent: Fri, February 4, 2011 5:04:29 AM
Subject: Re: [TinyOWS-dev] About encoding per layer and other things
On Feb 1, 2011, at 11:27 PM, Carlos Ruiz wrote:
First sorry for the delay...
> I was checking about the per layer encoding.
> First, when I've added the encoding attribute in the config.xml
> file, it was to be able to pull data from
> the server with the GetFeature request.
> This because I noticed that Quantum GIS wasn't loading my data
> complete. Doing some tests with
> the GetFeature request with a browser, there was a parsing error
> with no UTF-8 characters.
> That problem was now fixed with the changes I made, you can check at
> to see that the TinyOWS generated XML response handles the encoding
> ISO-8859-1 that I've
> defined into my config.xml file.
> Also, if you type ./wfst2 --check it dumps the encoding too:
> TinyOWS version: 0.9.0
> Config File Path: /usr/local/tinyows/config.xml
> PostGIS dsn: host=127.0.0.1 ...
> Schema dir: /usr/local/tinyows/schema/
> Log file: /usr/local/tinyows/tinyows.log
> Encoding: ISO-8859-1
> Available layers:
> - public.acatic_manzanas -> 32613 RW
> - public.acatic_cultivos -> 32613 RW
> - public.acatic_curvas_nivel_maestras -> 32613 RW
> Now, handling encoding per layer needs to specify per table
> PostgreSQL encodings, is not possible
> because you can only set the encoding to the whole database.
Yeap that's a good point, you're right !
> Also, there's no necessarily match between the XML encoding and the
> PostgreSQL encoding.
> Lets say:
> I need to handle the XML responses with an encoding that supports
> french and spanish special
> characters, so I have to choose ISO-8859-1, but, I have my database
> configured as LATIN-1
> or WIN1252. It doesn't match.
> So I suggest to add into the pg tag an encoding attribute, like this:
> <pg host="127.0.0.1" user="postgres" password="postgres"
> dbname="tinyows_demo" port="5432"
It could be,
But the global location in OWS also seems fine to me.
> With this change, I just can call the PQsetClientEncoding function
> after the connection is
> What do you think ?
I've took your last patch,
and made few modification before commit in trunk.
Thanks a lot ! :)
I let you check that everything is fine on your own,
Few little things from previous patch:
- Buffer struct is not directly a char * , but you could use buffer-
>buf if needed
- I didn't keep author comment inside the code (svn log and NEWS files
are dedicaded for that)
> There's another thing I'm seeing with the transaction code. It will
> be wise to use SELECT ... WITH
> UPDATE specification and also adding LOCKs while update or delete
> rows, to avoid concurrency
> However, this change might affect a little bit the performance
> (because the locks) but
> enhancing the
> data consistency.
> I'm currently doing some tests with that.
WFS-T specification already have a way to handle explicitly locks
But i didn't implemented them in TinyOWS for now.
If you have to explore this way, you should also have a look in
PostGIS Long Transaction features.
A patch for WFS-T lock implementation is welcome (since it's strictly
conform to OGC WFS-T spec)
But there's some problem IMHO in this OGC lock architecture,
as the client have to release himself each lock he already tooks.
(And sometime client will just forget too, or could exploit this
a security hole, kind of quick DoS)
So GeoServer for instance also provide via administration backoffice,
a way for administrator to list each lock and a way to release them if
And on the final point, i'm not sure that there's available WFS-T
able to deal with WFS lock handle...
TinyOWS-dev mailing list
TinyOWS-dev at lists.maptools.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TinyOWS-dev