Re: [Geotools-devel] An occasion to fix yet another feature collection issue?

2010-06-25 Thread Andrea Aime
christian.muel...@nvoe.at ha scritto: A big +1 one for this proposal, having our own FeatureAccessException with a Constructor FeatureAccessException(Exception ex). We actually always had that, DataSourceException, but for some reason people decided not to use it anymore. Honestly no

Re: [Geotools-devel] An occasion to fix yet another feature collection issue?

2010-06-25 Thread christian . mueller
Hy Ben, I am also bored with checked exceptions, but how to handle error situations ? Mostly, and exception is raised during IO. If I look at the java sdk, it is very unlucky that you have to catch an IOException if you work with Byte Streams. This is a trade off of the java stream design.

Re: [Geotools-devel] An occasion to fix yet another feature collection issue?

2010-06-25 Thread Ben Caradoc-Davies
-1 ** (2*n - 1) for me (where n is a natural number). Now, what about an SQLException with an IOException as its cause? Or vice versa? In my experience, developers designing their own exception hierarchy is a bad sign ... If this news exception is checked the first thing that is going to

Re: [Geotools-devel] An occasion to fix yet another feature collection issue?

2010-06-25 Thread Ben Caradoc-Davies
On 25/06/10 14:06, christian.muel...@nvoe.at wrote: I see to possibilities 1) Having our own checked exceptions 2) Having no checked exceptions and use runtime exceptions. I like (2). How about RuntimeException? For 2) it would be nice to have our own runtime exception class like

Re: [Geotools-devel] An occasion to fix yet another feature collection issue?

2010-06-25 Thread Andrea Aime
Ben Caradoc-Davies ha scritto: I am happy for libraries to throw exceptions, I just dislike the language micromanaging my handling of them. See this comment from Florence: hmm.. may be or may be it is related to issue ben just raised regarding no ioexception being catch in feature

[Geotools-devel] Daily issue building app-schema

2010-06-25 Thread Andrea Aime
Hi, every day I build Geotools, and every day I get this: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. No versions are

Re: [Geotools-devel] An occasion to fix yet another feature collection issue?

2010-06-25 Thread Jody Garnett
We already have DataSourceException that meets this need Christian. it is a checked exception however; I think what Ben is getting at is that we should: - make an unchecked exception - add it to our library where needed Jody On 25/06/2010, at 3:51 PM, christian.muel...@nvoe.at wrote: A big

Re: [Geotools-devel] An occasion to fix yet another feature collection issue?

2010-06-25 Thread Andrea Aime
Jody Garnett ha scritto: We already have DataSourceException that meets this need Christian. it is a checked exception however; I think what Ben is getting at is that we should: - make an unchecked exception - add it to our library where needed +1 on adding a similar chained runtime

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-25 Thread christian . mueller
Ben I will try to assist. A soon you make I patch I will check on other sdks. Quoting Ben Caradoc-Davies ben.caradoc-dav...@csiro.au: On 24/06/10 20:53, christian.muel...@nvoe.at wrote: H i Ben, this discussion stopped without a result. What are your next steps ? No, it stopped with the

[Geotools-devel] [jira] Created: (GEOT-3158) Add support for parametric VirtualTable in JDBC stores

2010-06-25 Thread Andrea Aime (JIRA)
Add support for parametric VirtualTable in JDBC stores -- Key: GEOT-3158 URL: http://jira.codehaus.org/browse/GEOT-3158 Project: GeoTools Issue Type: Improvement Components: data

[Geotools-devel] Patch for parametric sql views ready for review

2010-06-25 Thread Andrea Aime
Hi, I've just attached to http://jira.codehaus.org/browse/GEOT-3158 adding support for parameters in sql views. Given there has been quite some discussion on the list I though to give everybody notice about it. I've tried to strike a compromise about the parameter validation by rolling a very

[Geotools-devel] cql - unsuport old syntax

2010-06-25 Thread Mauricio Pazos
We have been supporting the deprecated syntax for the geometry relationships: intersect touch cross OGC corrected these syntax by the following intersects touches crosses We have been maintaining the old syntax since 2.6.1. I would like unsupport the old syntax for 2.7.x Is there any

[Geotools-devel] ecql - new syntax for ID Predicate

2010-06-25 Thread Mauricio Pazos
Hello everyone, recently, I have updated the syntax for id predicate The old syntax is: ID IN ('river.1', 'river.2') The new syntax is: IN ('river.1', 'river.2') or if you have an integer type as fid: IN (300, 301) etc In the future, if someone uses the old syntax the following warning

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-25 Thread Gabriel Roldan
My next step will be to submit bug fixes for the most egregious HashMap assumptions, referring to this discussion. looks like the right thing to do imho. Cheers! Gabriel -- ThinkGeek and WIRED's GeekDad team up for

Re: [Geotools-devel] ecql - new syntax for ID Predicate

2010-06-25 Thread Jody Garnett
Thanks Mauricio: I have updated the udig page here: - http://udig.refractions.net/confluence/display/EN/Common+Query+Language I am not sure about the integer type as fid; since for features we always turn the results into a string; usually by prefixing the type name. Jody On 25/06/2010, at

Re: [Geotools-devel] An occasion to fix yet another feature collection issue?

2010-06-25 Thread Jody Garnett
On 25/06/2010, at 5:47 PM, Andrea Aime wrote: +1 on adding a similar chained runtime exception to iterators, better than nothing. I will try and cook up a patch / proposal. However I have a dreaded insight; for our use case of using a while loop: you asked how often people need to do a try