sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SIS-180) Place a crude JDBC driver over Dbase files
Date Tue, 07 Oct 2014 01:59:33 GMT

    [ https://issues.apache.org/jira/browse/SIS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161359#comment-14161359
] 

Martin Desruisseaux commented on SIS-180:
-----------------------------------------

I wonder, if the first version limit itself to the {{SELECT * FROM <table>}} clause,
I wonder if we could start with a manually-written parser instead than using AntLR? I find
tools that generate code automatically useful for a quick start, but later become a limitation.
For example Sun initially written javac using such tools, and later abandoned it and rewrote
the full javac parser from scratch, manually. I had myself similar experience with the Well
Known Text (WKT) parser: the first version wrote 10 years ago was using something like AntLR,
and later we had to abandon it and rewrite everything from scratch. I believe that as the
text that we are tying to parse gains in complexity, the constraint of such tools become more
problematic.


> Place a crude JDBC driver over Dbase files
> ------------------------------------------
>
>                 Key: SIS-180
>                 URL: https://issues.apache.org/jira/browse/SIS-180
>             Project: Spatial Information Systems
>          Issue Type: Improvement
>          Components: Storage
>    Affects Versions: 0.5
>            Reporter: M. Le Bihan
>            Priority: Minor
>
> It would be useful to be able to query DBF content through SQL.
> But there are no free drivers available for the old _Dbase 3_ format.
> The first step is to create short implementations of _Connection_, _Statement_, _ResultSet_,
_ResultSetMetadata_ interfaces for a JDBC using our _Database_ class as core binary loader
at the begining.
> The main difficulty is to respond to a SQL request, and first : being able to analyze
it to understand what is expected.
> The SQL request analysis is a very strong job, but I suggest to ease it a lot by relying
on _AntLR_ API for grammar analysis, associated with a BNF grammar file, maybe taken from
^1^ or from elsewhere (grammars are of public domain).
> The goal of this current JIRA is only to be able to perform a 
> _SELECT * FROM <shapefile layer name>_
> The WHERE clause or the selection of fields, will come later in other JIRA.
> No transactions, classic _Statement_ only.
> _PreparedStatement_ would be also implemented later (another JIRA).
> Of course, this improvment can be discarded if an open source or free driver is discovered,
that would allow us to execute SQL requests on DBase 3 easily.
> ^1^ For example, [http://www.savage.net.au/SQL/] has some BNF, but maybe elsewhere they
will more compliant with AntLR.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message