sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (JIRA)" <>
Subject [jira] [Commented] (SIS-180) Place a crude JDBC driver over Dbase files
Date Wed, 15 Oct 2014 04:52:34 GMT


Martin Desruisseaux commented on SIS-180:

On the star imports, there is no absolute rule. This is a compromise depending on the amount
of imports. If there is only 3 or 4 classes to import from a package, enumerating them does
not pollute the code so much. But if a package is imported almost entirely, then a star import
makes lot of sense. Between the 2 the frontier is not clear.

The reason for enumerating the imports explicitly is to protect the code against name collision
between two packages. The problem may not exist at the time of writing a code, but appears
later when new classes are added in the imported packages. An historical example is the name
collision between {{java.awt.List}} and {{java.util.List}} when the later has been added to
Java 1.2: some code using start imports that compiled under Java 1.1 did not compiled anymore
under Java 1.2.

However I agree about long list of imports not being easy to read - there is a balance somewhere
between enumerating everything and all start imports.

> Place a crude JDBC driver over Dbase files
> ------------------------------------------
>                 Key: SIS-180
>                 URL:
>             Project: Spatial Information Systems
>          Issue Type: Improvement
>          Components: Storage
>    Affects Versions: 0.5
>            Reporter: M. Le Bihan
>            Assignee: Martin Desruisseaux
>            Priority: Minor
>             Fix For: 0.5
>         Attachments:
> 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, [] has some BNF, but maybe elsewhere they
will more compliant with AntLR.

This message was sent by Atlassian JIRA

View raw message