Experiences with GNATColl.SQL ORM?

Experiences with GNATColl.SQL ORM?

[Jacob Sparre Andersen]

Can somebody report on their experiences with the Object-Relational
Mapping (ORM) layer in GNATColl.SQL?

We are using plain GNATColl.SQL at AdaHeads, and I am experimenting with
it for some other projects, but I would like to use ORM and not the
untyped GNATColl.SQL interface.

I have tried to run the "gnatcoll_db2ada" tool on our data model for
Alice, but it fails with an internal error:

A database error occurred, please try again...
Exception name: CONSTRAINT_ERROR
Message: gnatcoll-sql-inspect.adb:174 access check failed

This does not make me very confident of the quality of the ORM layer of
GNATColl.SQL. :-(

Are there any alternatives out there?  (The requirements are that the
persistence backend shouldn't be specific to the tool and that the
storage access should be strongly typed.)

Greetings,

Jacob
-- 
<URL: small-talk://work/hallway-meeting/...>

Re: Experiences with GNATColl.SQL ORM?

[Dmitry A. Kazakov]

On Thu, 19 Dec 2013 15:53:12 +0100, Jacob Sparre Andersen wrote:

> A database error occurred, please try again...
> Exception name: CONSTRAINT_ERROR
> Message: gnatcoll-sql-inspect.adb:174 access check failed

A strayed accessibility check? Maybe, replacing Access with
Unchecked_Access would cure it.

> Are there any alternatives out there?  (The requirements are that the
> persistence backend shouldn't be specific to the tool and that the
> storage access should be strongly typed.)

A different approach:

http://www.dmitry-kazakov.de/ada/components.htm#persistent_objects

Supported back-ends are ODBC and SQLite3. APQ was dropped due to lack of
maintenance.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Experiences with GNATColl.SQL ORM?

[Jacob Sparre Andersen]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Thu, 19 Dec 2013 15:53:12 +0100, Jacob Sparre Andersen wrote:

>> A database error occurred, please try again...
>> Exception name: CONSTRAINT_ERROR
>> Message: gnatcoll-sql-inspect.adb:174 access check failed
>
> A strayed accessibility check? Maybe, replacing Access with
> Unchecked_Access would cure it.

I'll take a look at that possibility.

>> Are there any alternatives out there?  (The requirements are that the
>> persistence backend shouldn't be specific to the tool and that the
>> storage access should be strongly typed.)
>
> A different approach:
>
> http://www.dmitry-kazakov.de/ada/components.htm#persistent_objects
>
> Supported back-ends are ODBC and SQLite3. [...]

Reading the documentation, it seems like the actual storage is as
strings, and not as types equivalent to those used on the Ada side.  Is
that correct?

Greetings,

Jacob
-- 
Compiled code speed is not the _really_ important speed of a programming language.
What's important is the speed of:
- Implementing a complex algorithm by an average programmer, including bug-fixing.
- Understanding an implementation of a complex algorithm for an average programmer.

Re: Experiences with GNATColl.SQL ORM?

[Dmitry A. Kazakov]

On Thu, 19 Dec 2013 18:21:49 +0100, Jacob Sparre Andersen wrote:

> Reading the documentation, it seems like the actual storage is as
> strings, and not as types equivalent to those used on the Ada side.  Is
> that correct?

Yes, it is a standard OO serialize/deserialize schema. Objects are stored
as blobs. Object's types and dependencies are stored independently.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de