SQL/database server capabilities NO ODBC please

bls bizprac at orange.fr
Sun Dec 4 17:47:07 PST 2011


On 11/26/2011 10:13 PM, Steve Teale wrote:
> On Sat, 26 Nov 2011 15:31:33 -0800, bls wrote:
>
>> Hi Steve
>> First of all : I am sorry about my harsh words within my last reply. ---
>> I am afraid that this feedback is also not very gentle.
>>
>> Picking up ODBC in order to figure out how an generic database Interface
>> may look like is a very bad idea.
>>
>> Creating an ODBC Interface at all is pretty useless. NOBODY is using
>> ODBC at all.
>>
>> Creating std.database based on sockets is useless. Let's take MySQL for
>> instance.  In case that you create a commercial application based on
>> MySQL you have to pay fees to ORACLE ( approx. 1000 Euro, per Server)
>> and nobody cares about your BOOST licensed Phobos raw socket stuff..
>>
>> Despite that : std.database becomes unmaintainable. I've had a look at
>> your sources, Tough stuff.  Same is valid Piotr's PostgreSQL
>> implementation.
>>
>> NO!.
>> I am all against it. I think that implementing std.database requires
>> understanding of Martin Fowler's  Enterprise patterns, As said before :
>> Function follows Form  :)
>>
>> Last, and most probably useless comment, Have a look at
>> http://www.sqlalchemy.org/
>>
>> Cheers,
>> Bjoern
>
> Bjoern,
>
> No need for apologies, the D newsgroup is a hard school.
>
> The intro for SQLAlchemy says:
>
> "Over five years of constant development, profiling, and refactoring has
> led to a toolkit that is high performing and accurate, well covered in
> tests, and deployed in thousands of environments."
>
> The situation for D is probably roughly as follows:
>
> "About three months  of experimentation, and struggle with inaccurate
> documentation, has led to a point where a group of three or four of us
> can communicate reasonably effectively with four database systems - MySQL
> (API and Protocol), SQLite, PostgreSQL (API and Protocol), and SQL Server
> (from Linux and from Windows vis ODBC).
>
> We are learning to walk. To do the things SQLAlchemy describes, I think
> you have to understand how to do that.
>
> You may detest ODBC, but it is very soon going to be the only way to
> communicate with SQL Server short of writing another wire protocol
> effort.  There was the alternative of OLE DB, but MS is dumping that.
>
> In another post under the std.database thread I have already suggested
> that the post of top-down high level designer is certainly up for grabs.
> Do you fancy it? Maybe by the time the top level design is completed,
> Piotr and I and and others will have the means to do the nitty-gritty
> lower-level stuff. in a reasonably consistent way.
>
> Steve

Point taken! Thanks. :)
Despite that....  hope you will agree with me that following/mimic JDBC 
instead of ODBC makes more sense.

Sure, it's your turn and  ..
asinus sacuum portat.

so I'd better shut up.
Bjoern


More information about the Digitalmars-d mailing list