October 06, 2012 Re: The sorry state of the D stack? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On 2012-10-06 22:59, Nick Sabalausky wrote: > DSSS has been dead for a long time, I don't know why an active project > like GtkD is apparently mentioning it. DSSS is working just fine for D1. GtkD works both with D1 and D2. -- /Jacob Carlborg |
October 06, 2012 Re: The sorry state of the D stack? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Sat, 06 Oct 2012 23:27:55 +0200 Jacob Carlborg <doob@me.com> wrote: > On 2012-10-06 22:59, Nick Sabalausky wrote: > > > DSSS has been dead for a long time, I don't know why an active project like GtkD is apparently mentioning it. > > DSSS is working just fine for D1. I don't know about the rest of DSSS as I only ever used the 'rebuild' component. But as for rebuild, there are problems: For one thing, 0.76 is generally considered to work much better than 0.77 and the final version, 0.78 (I forget the details, but a lot of people including me have had problems with 0.78 that never showed up with 0.76). But despite that, read-made builds aren't available for 0.76. As DSSS is dead none of this is likely to get fixed. And there's no reason to fix rebuild since RDMD is a superior and non-dead alternative to rebuild. Also, rebuild is slow, even with "one at a time" disabled. Try compiling DVM with the included rebuild-based script and the RDMD-based one. It takes a fair amount of time with rebuild (even with "one at a time" off), but with RDMD it's almost instant. There's no reason for anyone to use rebuild anymore, and very few people do. > GtkD works both with D1 and D2. > So does RDMD, unless I'm mistaken. |
October 06, 2012 Re: The sorry state of the D stack? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Thomas Koch | On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote: >> - I looked for a PostgreSQL client library. I found small > personal hacks and > dead projects. https://github.com/denizzzka/dpq2 This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd. I really need users, comments, suggestions, bug reports and commits. |
October 07, 2012 Re: The sorry state of the D stack? | ||||
---|---|---|---|---|
| ||||
Posted in reply to denizzzka | denizzzka wrote: > https://github.com/denizzzka/dpq2 Thank you very much. I think I haven't seen this project. Would you like to add it to this wiki page? http://www.prowiki.org/wiki4d/wiki.cgi?DatabaseBindings#PostgreSQL Best regards, Thomas Koch |
October 07, 2012 Re: SQL working [ was Re: The sorry state of the D stack? ] | ||||
---|---|---|---|---|
| ||||
Posted in reply to denizzzka Attachments:
| On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote: > On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote: > >> - I looked for a PostgreSQL client library. I found small > > personal hacks and > > dead projects. > > https://github.com/denizzzka/dpq2 > > This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd. > > I really need users, comments, suggestions, bug reports and commits. Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? From the example I assume that this is just a library for managing connections and that everything else is just string-based SQL statements. Groovy's and Python's lowest level is roughly the same. However on top of these are expression languages in Groovy / Python so as to remove the reliance on string processing, i.e. use an internal DSL to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it will hopefully be GSQL. I am sure Scala and C++ have something similar? So I guess the question is how to ensure this all works with all SQL systems and how to put an abstraction layer over this to avoid all the error prone string manipulation? -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder |
October 07, 2012 Re: SQL working [ was Re: The sorry state of the D stack? ] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | On Sunday, 7 October 2012 at 09:07:39 UTC, Russel Winder wrote: > On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote: >> On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote: >> >> - I looked for a PostgreSQL client library. I found small >> > personal hacks and >> > dead projects. >> >> https://github.com/denizzzka/dpq2 >> >> This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd. >> >> I really need users, comments, suggestions, bug reports and commits. > > Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, > PervasiveSQL, SQLite3, etc.? > Probably if someones needs work to be done in ie PostreSQL won't care about other DBMS at the time of being. There are other projects for Database handling. - There is SQLd [http://github.com/robik/sqld], that focus on multiple database drivers. Some designs flaws are inherited from SQLAlchemy. Looks promising. - There is DBMI on DSource. I am not 100% sure if it works with D2 tho (but porting should be rather trivial). - Many, many other projects like that shattered on Github/BitBucket/DSource(?) > From the example I assume that this is just a library for managing > connections and that everything else is just string-based SQL > statements. Groovy's and Python's lowest level is roughly the same. > However on top of these are expression languages in Groovy / Python so > as to remove the reliance on string processing, i.e. use an internal DSL > to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it > will hopefully be GSQL. I am sure Scala and C++ have something similar? > > So I guess the question is how to ensure this all works with all SQL > systems and how to put an abstraction layer over this to avoid all the > error prone string manipulation? > Probably because of reason I mentioned before. But yeah, after first glance it looks like project ready for some bigger tasks |
October 07, 2012 Re: The sorry state of the D stack? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joseph Rushton Wakeling | On Saturday, 6 October 2012 at 21:19:58 UTC, Joseph Rushton Wakeling wrote:
> On 10/06/2012 10:59 PM, Nick Sabalausky wrote:
>> Definitely not. *DSource* is dying, unfortunately, which has lead some
>> people to assume the same of the rest of D. But no, D is going very
>> strong, and has only been getting bigger.
>
> Might be worth placing some prominent message on DSource stating that it's being maintained to document all the D1 work and projects, but that the active work is now over at dlang.org?
+1
Getting tired of people heading to dsource and assuming that D is dead.
|
October 07, 2012 Re: SQL working [ was Re: The sorry state of the D stack? ] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | Russel Winder wrote: > On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote: >> On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote: >>>> - I looked for a PostgreSQL client library. I found small >>> personal hacks and >>> dead projects. >> >> https://github.com/denizzzka/dpq2 >> >> This is my personal project but it is not dead, and I am >> determined to see it through. At the moment, it is quite suitable >> to be used in simple situations. Compiles without warnings by dmd >> 2.060, also it can be used with rdmd. >> >> I really need users, comments, suggestions, bug reports and >> commits. > > Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, > PervasiveSQL, SQLite3, etc.? I wrote a PostgreSQL client too, but I also want to make MySQL and SQlite clients/wrappers and release them all at once. This is because I want to create uniform DB interface, and it must be suited for all database systems. I started with PostgreSQL because it's most complex of the three, for instance it supports array and struct fields. > From the example I assume that this is just a library for managing > connections and that everything else is just string-based SQL > statements. Groovy's and Python's lowest level is roughly the same. > However on top of these are expression languages in Groovy / Python so > as to remove the reliance on string processing, i.e. use an internal DSL > to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it > will hopefully be GSQL. I am sure Scala and C++ have something similar? As you've said, additional DSL/Abstract layer must be on built on the string based library. We should finish that first. |
October 07, 2012 Re: The sorry state of the D stack? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | On Sunday, October 07, 2012 11:43:21 Peter Alexander wrote:
> On Saturday, 6 October 2012 at 21:19:58 UTC, Joseph Rushton
>
> Wakeling wrote:
> > On 10/06/2012 10:59 PM, Nick Sabalausky wrote:
> >> Definitely not. *DSource* is dying, unfortunately, which has
> >> lead some
> >> people to assume the same of the rest of D. But no, D is going
> >> very
> >> strong, and has only been getting bigger.
> >
> > Might be worth placing some prominent message on DSource stating that it's being maintained to document all the D1 work and projects, but that the active work is now over at dlang.org?
>
> +1
>
> Getting tired of people heading to dsource and assuming that D is dead.
Isn't part of the problem that no one can get ahold of the person who runs it? At least, that's what I remember being discussed previously. It was my understanding that that's why we've never been able to get dsource cleaned up or really changed at all.
- Jonathan M Davis
|
October 07, 2012 Re: SQL working [ was Re: The sorry state of the D stack? ] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Piotr Szturmaj | On Sunday, 7 October 2012 at 09:56:30 UTC, Piotr Szturmaj wrote:
> Russel Winder wrote:
>> On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote:
>>> On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote:
>>>>> - I looked for a PostgreSQL client library. I found small
>>>> personal hacks and
>>>> dead projects.
>>>
>>> https://github.com/denizzzka/dpq2
>>>
>>> This is my personal project but it is not dead, and I am
>>> determined to see it through. At the moment, it is quite suitable
>>> to be used in simple situations. Compiles without warnings by dmd
>>> 2.060, also it can be used with rdmd.
>>>
>>> I really need users, comments, suggestions, bug reports and
>>> commits.
>>
>> Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2,
>> PervasiveSQL, SQLite3, etc.?
>
> I wrote a PostgreSQL client too, but I also want to make MySQL and SQlite clients/wrappers and release them all at once. This is because I want to create uniform DB interface, and it must be suited for all database systems. I started with PostgreSQL because it's most complex of the three, for instance it supports array and struct fields.
>
I would also look at commercial DB, otherwise you might still find a few surprises while defining an uniform DB.
I went through that pain back in 1999-2001, when we were defining an abstraction mechanism in TCL/C to bind to multiple databases, akin to ActiveRecord on Ruby.
For example, on those days using only ODBC was not enough for SQL Server 6. We also needed to make use of another binding provided for compatibility with Sybase SQL Server, to be able to offer all the same API when using SQL Server as DB. That took awhile to figure out how to integrate into the existing architecture.
--
Paulo
|
Copyright © 1999-2021 by the D Language Foundation