<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><br><br><div>> Date: Wed, 21 Aug 2013 17:35:18 +0100<br>> Subject: Re: [pycsw-devel] Issues with the PostGIS backend + real live metadata<br>> From: adria.mercader@okfn.org<br>> To: tomkralidis@hotmail.com<br>> CC: gcpp.kalxas@gmail.com; pycsw-devel@lists.osgeo.org<br>> <br>> Thanks Angelos and Tom for the quick merges and comments,<br>> <br>> On 21 August 2013 16:11, Tom Kralidis <tomkralidis@hotmail.com> wrote:<br>> <br>> > On 2013-08-21, at 11:02, "Angelos Tzotsos" <gcpp.kalxas@gmail.com> wrote:<br>> ><br>> > On Wed, Aug 21, 2013 at 1:54 PM, Adrià Mercader <adria.mercader@okfn.org><br>> > wrote:<br>> ><br>> > I usually create plpythonu functions even if PostGIS is present. This way if<br>> > for some reason postgis gets unavailable in the future, pycsw will continue<br>> > to work.<br>> > But yes, you understood correctly, thanks for the fix.<br>> <br>> The plpythonu functions add complexity to the setup process and future<br>> migrations of the db, as they need to be created by a superuser, so<br>> we'd rather avoid them.<br>> <br>> <br>> >> * On several documents I tried I got exceptions because the fields<br>> >> defined were too short:<br>> >><br>> >> DataError('(DataError) value too long for type character varying(256)\n',)<br>> >><br>> >> See eg the abstract field in [3][4] or conditionapplyingtoaccessanduse<br>> >> in [5] (you find this with much more fields once you start importing<br>> >> large numbers of records).<br>> >> I'm not a DB expert, and I certainly can't talk for sqlite, but I<br>> >> would imagine that changing the column definitions to character<br>> >> varying(x) to text would have no effect on performance while removing<br>> >> all kind of text length limit problems. This is a good resource [6]<br>> ><br>> ><br>> > +1<br>> ><br>> > +1. Can someone open a ticket here?<br>> ><br>> > Adrià: this fix we can't backport to 1.6 branch, so the fix will be applied<br>> > to master (which will end up in 1.8.0).<br>> ><br>> > Is this okay with you? Can you libe with this in master until 1.8.0 is cut?<br>> > Not sure what your pycsw version requirements are.<br>> <br>> We will require whatever version that will include the 2 previous<br>> fixes (indent and srid typo), which are the ones the prevent our<br>> setup. I assume those will be available on a 1.6.x version.<br>> This one would be nice to have, but we can let users decide as maybe<br>> it does not affect their metadata.<br>> <br><br>1.6.1 (hours/days away) will have your PR. The loosening of the DB column types will be in 1.8.0<br><br>> ><br>> >><br>> >> * As a really minor general comment, the exceptions raised while<br>> >> loading documents [8] are a bit too noisy, as they output the whole<br>> >> document, making difficult to know what actually went wrong.<br>> ><br>> > Yes this is true.<br>> > Fixed in master and 1.6 branch.<br>> Great<br>> <br>> <br>> Adrià<br>> <br>> <br>> <br>> ><br>> ><br>> >><br>> >><br>> >> Hope this helps,<br>> >><br>> >> Adrià<br>> >><br>> ><br>> > Best,<br>> > Angelos<br>> ><br>> ><br>> ><br>> ><br>> > --<br>> > Angelos Tzotsos<br>> > Remote Sensing Laboratory<br>> > National Technical University of Athens<br>> > http://users.ntua.gr/tzotsos<br>> ><br>> > _______________________________________________<br>> > pycsw-devel mailing list<br>> > pycsw-devel@lists.osgeo.org<br>> > http://lists.osgeo.org/mailman/listinfo/pycsw-devel<br></div> </div></body>
</html>