[fdo-internals] RFC 52 -- Convenience C++ API wrapper for FDO

[Haris Kurtagic]

Hi Traian,

I think C interface could be very good match for FDO.
As a meter of fact "fdolite_" similar to "sqlite3_..." interface could
be very nice way to work with fdo.

Haris

On Mon, Aug 9, 2010 at 7:10 PM, Traian Stanev
<traian.stanev at autodesk.com> wrote:
>
> Hi Haris,
>
> First things first, I love C and I think it's the best programming language, certainly far better than C++. However, I think C would be a non-optimal solution to the problem, given the specific problem space. C wrappers would be far more verbose and a bit more unsafe for the target audience of this wrapper, which is people who already think that FDO is too verbose and unsafe. For example, with C it would not be possible to automatically release connections back to the pool when they go out of scope.
>
> About the one query per table. Actually, you are limited to one query per table, but you are not limited to the number of tables you can have pointing to the same original database table. What you are seeing in Table is an artifact of the conversion from purely an FDO wrapper to a generic one, but for example it is actually possible to declare as many TableFdo's as you need queries. That's actually how I've been using it for a while now -- it's easier if you look at the table as representing a select (or insert, or update) query, rather than an actual table.
>
> The Tables provided by the database object are there for convenience, since in most cases a Database is owned by a single thread, so it's likely to be doing things sequentially.
>
> About the CreateConnection from .dll name. It would help, but it's certainly not critical -- I've been doing automatic provider dll loading for a long time now, since the connection manager is a pain to use, and the wrapper already contains code for that.
>
> Traian
>
>
>> -----Original Message-----
>> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
>> bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
>> Sent: Monday, August 09, 2010 7:01 AM
>> To: FDO Internals Mail List
>> Subject: Re: [fdo-internals] RFC 52 -- Convenience C++ API wrapper for
>> FDO
>>
>> Hi Traian,
>>
>> It is great move, from talk to talk&c++.
>> I certainly like that you started on coding on this idea. It has be
>> just talk for some time now :)
>>
>> My first question would be have you considered having just c interface ?
>>
>> I quickly went trough code too.
>> Using one Table per class  and keep command and queries in it, sound
>> like a limiting to have just one query or command per table(class).
>> Exposing results of query "recordset" trough separate object could be
>> way to go ?
>>
>> On side note: I see you are already need  "Monday" submit for Fdo
>> CreateConnection from .dll filename
>>
>> Thanks,
>> Haris
>>
>>
>>
>> On Mon, Aug 9, 2010 at 1:14 AM, Traian Stanev
>> <traian.stanev at autodesk.com> wrote:
>> > Hello all,
>> >
>> > As you know, I have recently complained about FDO API complexity [1].
>> Complaining is nice and all, but it's better done in C/C++ form, so I
>> have posted a proposal for API simplification as FDO RFC 52. The
>> proposal includes a working draft implementation.
>> >
>> > If interested, have a look, I'd be interested in comments and
>> suggestions for improvement of the design and implementation.
>> >
>> > http://trac.osgeo.org/fdo/wiki/FDORfc52
>> >
>> > Thanks,
>> > Traian
>> >
>> >
>> > [1] http://osgeo-org.1803224.n2.nabble.com/resignation-from-FDO-PSC-
>> td5302376.html#a5302376
>> >
>> > _______________________________________________
>> > fdo-internals mailing list
>> > fdo-internals at lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/fdo-internals
>> >
>> _______________________________________________
>> fdo-internals mailing list
>> fdo-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>