Part of major reorganization of gnatcoll for better modularity and
maintainability.
Change-Id: Iad961b53634520081eb90c37aff2bfdbf58b2e06
TN: P909-033 no-precommit-check
This reverts commit ddc7448693566d8433a8ff04e4b3cb5beac3451f, reversing
changes made to e9a7649d7abe47f6bdaa88a97871842692152ec1.
Change-Id: I2fb1cd4e5f67eeef6e7402b4f61af0a0cdf1ebf5
This commit aggregates multiple smaller commits, and provides the
following major reorganization to GNATCOLL.SQL*
(gnatcoll_db2ada):
report an error when the user used a wrong keyword
In a database schema description, tables should start with TABLE,
ABSTRACT TABLE or VIEW. Report an error in other cases
(database description files):
Add support for different type name in schema description and SQL.
In some cases, users might want to use a different name in the schema
description files than actually used by SQL.
Custom field types
A single generic package instantiation is needed to create custom field
types. This is also used for all predefined field types.
This avoids duplication of information between the three or four
instantiations we had to do before, and ensures better consistency. For
instance, a SQL_Field_Float was sometimes mapped to "float" and
sometimes to "real". Likewise, a time field was sometimes a "timestamp"
and sometimes a "timestamp with time zone".
This also ensures that users do not forget to register their custom
types, or to make them available to database description files and
gnatcoll_db2ada.
fix mapping of "numeric"
"numeric" should be mapped to a float, but "numeric(precision)" should
be an integer (It has a scale of 0), as well as "numeric(precision,0)".
And "numeric(position,scale)" with a scale other than 0 should be a
float.
Map a sql "numeric(precision,scale)" to Ada Long_Long_Float.
A Float is not enough to represent the full precision.
Fix duplicate type definition in GNATCOLL (SQL_Field_Long_Float).
In particular, one of the definitions was mapping a "float" in a
database description file to an Ada "Float", though the documentation
in gnatcoll-sql.ads says these were mapped to Long_Long_Float.
(Long_Float_Value): renamed to Long_Long_Float_Value for consistency.
In fact, long float fields are implemented as Long_Long_Float, so we
had an inconsistency which is now easier to detect with the new
organization of generic packages.
(Cast): function moved to the generic Field_Types
It is now easier for people writing custom sql types to have access to
"CAST (field AS type)" functions
Simplify handling of parameter types
(Field_Mapping): no longer needs to know about parameter types, just the
SQL name is enough. This simplifies instantions of
Simple_Field_Mapping, makes things more efficient, and will make it
possible to move this type directly in the Field_Types package, to ease
creating new custom types.
(SQL_Parameter_Type): remove the Type_String primitive operation, not
needed since we never override it anyway. Minor efficiency gain.
Use XString is more place, instead of String_Access, also for efficiency
since most of the time the strings are small. So we are saving on
mallocs.
Ranges
We need to retrieve a type with static bounds which can be manipulated
from Ada. Previously we were retrieving a SQL type, whose bounds could
be defined as SQL functions.
(Ada_Range): is now a pure Ada type (unrelated to SQL) which can be
used to perform interval operations. At some point, it might make
sense to make it into a top-level GNATCOLL package.
Dates
When we create a date with Ada.Calendar.Time_Of (with no seconds),
then depending on the timezone it is possible that the resulting
string was set to the day before.
For instance, the sql/ranges test was using an Ada Time 2017-12-31,
but the string '2017-12-30' was passed to postgres when run from
Paris timezone in the morning.
Change how we override default getters for cursors. A DBMS_Cursor used
to have primitives to convert the return value (usually a string) to
a more specific Ada type. But in fact, we need those functions at the
level of the formatter (postgresql or sqlite) so that we can parse a
range value's bounds.
Testsuite
Skip tests that require running postgresql, when the current
environment does not provide this.
Fix bug when the session is configured with Store_Unmodified set to False:
when an element is retrieved through Get_Customer for instance, it isn't
added to the session cache as per the settings. But then when we modify
the element is still wasn't added to the cache because its session was
already set. As a result the change was never committed to the database.
K729-010
git-svn-id: svn+ssh://svn.eu.adacore.com/Dev/trunk/gps@177011 936e1b1b-40f2-da11-902a-00137254ae57
Fixes Storage_Error in sqlite support, where a prepared statement could
be finalized before a cursor that used it. This is unlikely to occur in
complex application where prepared statements are expected to be global
variables, but would make the simple example more complex than need be
(using subprograms or declare blocks to control the order of finalization)
K729-010
git-svn-id: svn+ssh://svn.eu.adacore.com/Dev/trunk/gps@177001 936e1b1b-40f2-da11-902a-00137254ae57
This now documents how to load a fixture file in the database, continuing
the example started in the previous checkin
We also build this library example from the testsuite, to ensure the doc
is still up-to-date
(GNATCOLL.SQL.Inspect.Read_Schema): change profile to make it easier to
read a schema. This avoids the use of a declare block in the example and
makes for more readable code.
K729-010
git-svn-id: svn+ssh://svn.eu.adacore.com/Dev/trunk/gps@176969 936e1b1b-40f2-da11-902a-00137254ae57
The documentation now documents a step-by-step approach to building
an application with persistence. The example is filed separately so
that we can compile it and test that it works.
Fixes the parser for the database schema: a table can inherit its
primary key from its parent table.
Fixes gnatcoll_db2ada --createdb: since we were passing a model with
--dbmodel, we were in fact never connecting to the database, and thus
never creating it.
git-svn-id: svn+ssh://svn.eu.adacore.com/Dev/trunk/gps@176965 936e1b1b-40f2-da11-902a-00137254ae57
