From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,67748e866d067110 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Alex R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: SOCI-Ada: The Database Access Library for Ada Date: Tue, 19 Aug 2008 11:01:56 +0200 Message-ID: <6gvgg4Fhnt70U1@mid.individual.net> References: <9fa4c3e0-86bc-4a7d-98fb-6be76cb8aa68@d1g2000hsg.googlegroups.com> <6g0hikFdkv5oU1@mid.individual.net> <21f1f8b4-8e25-4b3f-90fa-004595237c1a@e39g2000hsf.googlegroups.com> <6g313lFe18jnU1@mid.individual.net> <88a4c984-53e3-4909-ace9-19c3cedf4851@c65g2000hsa.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: individual.net 0RDvelZfVu+Q0179tlggzgDDE6T/hG3n4N6kgNA3AMG1qL3Qg= Cancel-Lock: sha1:Nmz5DuRGsefBAe7HBY3hUXP1QeQ= User-Agent: KNode/0.10.9 Xref: g2news1.google.com comp.lang.ada:1647 Date: 2008-08-19T11:01:56+02:00 List-Id: (back from vacancy) Maciej Sobczak wrote: > Note that in the C++ version of SOCI there is also a lot contributed > by temporary objects. For example, here: > > int salary; > int id = 123; > sql << "select salary from persons where id = :id", > into(salary), use(id); > > there is a temporary (and invisible) object that has lifetime spanning > to the end of the full expression and that provides a hook for actual > statement execution. The statement cannot be executed before gathering > all the information, including variable binding, and the temporary > object is a nice way to "subscribe" the the end-of-expression point. > This is possible because temporary objects are part of the language > and they have well-defined lifetimes. > I see no way to even come close with Ada. > Another issue is that in Ada operators produce results that need to be > "consumed" (either assigned to something or used in bigger > expressions). This excludes the use of operators at the "top level" of > the statement. > Even something as simple as this: > > cout << "Hello"; > > cannot have a simple equivalent in Ada. > > Note that I do not want to imply that C++ is better than Ada in these > examples - everything has its price and the issues with temporary > objects or the ability of the expression results to be silently > ignored create lots of opportunities for problems to creep in. I have > just read a coding standard that forbids operator overloading > whatsoever - and it was justified. > > These are just two different language cultures. I don't think it makes > sense to cram one into another - the resulting bricolage might be > indigestible and this is certainly not in the interest of the library. > > But I'm open for any suggestions. I just cannot come up with anything > reasonable on my own. I see what you say. My C++ is certainly rusty (not seriously used for some like 4 years), but I remember "fun" times with temporaries. I'm not really prepared to offer a solution right now, but who knows. I have the gut feeling that something somewhat similar could be done without incurring in Ada bending, but I'd need to think it carefully. Likewise I could be wrong, if you have already devoted some time to this. (snip) >> and a matrix view of results > > Why would you ever want it? The database rowset is not a random-access- > thingy. > Note that at least in theory it might be possible for the database to > produce the result without actually having the full span on the > resulting rowset (and without possibility to rewind back). > If you need a matrix, copy the result (using the batch idiom) to the > matrix created specifically for this purpose. This is basically what I had in mind. >> I always end >> implementing something like that. > > And I've never seen any need for this. It's certainly not something necessary; it's more a personal preference. I find more natural to iterate over a matrix. It incurs in some memory overhead, but for small queries it's OK. >> I have a small project with only a few database queries that now are really >> ugly (because the library I'm using can't bind vars to values and thus >> there's a lot of string concatenation). > > Probably it also introduces some security issues. It likely would, if it were not strictly private... Even so I guess it's more open to zap something in the database if I make some mistake. (snip) Cheers, Alex.