[pycsw-devel] Issues with the PostGIS backend + real live metadata

[Tom Kralidis]

> Date: Wed, 21 Aug 2013 17:35:18 +0100
> Subject: Re: [pycsw-devel] Issues with the PostGIS backend + real live metadata
> From: adria.mercader at okfn.org
> To: tomkralidis at hotmail.com
> CC: gcpp.kalxas at gmail.com; pycsw-devel at lists.osgeo.org
> 
> Thanks Angelos and Tom for the quick merges and comments,
> 
> On 21 August 2013 16:11, Tom Kralidis <tomkralidis at hotmail.com> wrote:
> 
> > On 2013-08-21, at 11:02, "Angelos Tzotsos" <gcpp.kalxas at gmail.com> wrote:
> >
> > On Wed, Aug 21, 2013 at 1:54 PM, Adrià Mercader <adria.mercader at okfn.org>
> > wrote:
> >
> > I usually create plpythonu functions even if PostGIS is present. This way if
> > for some reason postgis gets unavailable in the future, pycsw will continue
> > to work.
> > But yes, you understood correctly, thanks for the fix.
> 
> The plpythonu functions add complexity to the setup process and future
> migrations of the db, as they need to be created by a superuser, so
> we'd rather avoid them.
> 
> 
> >> * On several documents I tried I got exceptions because the fields
> >> defined were too short:
> >>
> >> DataError('(DataError) value too long for type character varying(256)\n',)
> >>
> >> See eg the abstract field in [3][4] or conditionapplyingtoaccessanduse
> >> in [5] (you find this with much more fields once you start importing
> >> large numbers of records).
> >> I'm not a DB expert, and I certainly can't talk for sqlite, but I
> >> would imagine that changing the column definitions to character
> >> varying(x) to text would have no effect on performance while removing
> >> all kind of text length limit problems. This is a good resource [6]
> >
> >
> > +1
> >
> > +1. Can someone open a ticket here?
> >
> > Adrià: this fix we can't backport to 1.6 branch, so the fix will be applied
> > to master (which will end up in 1.8.0).
> >
> > Is this okay with you? Can you libe with this in master until 1.8.0 is cut?
> > Not sure what your pycsw version requirements are.
> 
> We will require whatever version that will include the 2 previous
> fixes (indent and srid typo), which are the ones the prevent our
> setup. I assume those will be available on a 1.6.x version.
> This one would be nice to have, but we can let users decide as maybe
> it does not affect their metadata.
> 

1.6.1 (hours/days away) will have your PR.  The loosening of the DB column types will be in 1.8.0

> >
> >>
> >> * As a really minor general comment, the exceptions raised while
> >> loading documents [8] are a bit too noisy, as they output the whole
> >> document, making difficult to know what actually went wrong.
> >
> > Yes this is true.
> > Fixed in master and 1.6 branch.
> Great
> 
> 
> Adrià
> 
> 
> 
> >
> >
> >>
> >>
> >> Hope this helps,
> >>
> >> Adrià
> >>
> >
> > Best,
> > Angelos
> >
> >
> >
> >
> > --
> > Angelos Tzotsos
> > Remote Sensing Laboratory
> > National Technical University of Athens
> > http://users.ntua.gr/tzotsos
> >
> > _______________________________________________
> > pycsw-devel mailing list
> > pycsw-devel at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/pycsw-devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pycsw-devel/attachments/20130821/80cc54b1/attachment.html>