On 1/9/16 6:02 AM, Russel Winder via Digitalmars-d wrote:
> Assuming EBNF is actually a good way of writing grammers.;-)

What would be a better way? -- Andrei

I've played with the idea of using operator overloading for some kind of ORM before, but I don't think it's strictly necessary to use operator overloading for an ORM at all. Maybe in some cases it might make sense.

I don't think the answer for building such a thing is to think of one idea, find out it won't work out well, and then give up. You have to be more creative than that.

On Tuesday, 12 January 2016 at 12:53:29 UTC, w0rp wrote:
> I've played with the idea of using operator overloading for some kind of ORM before, but I don't think it's strictly necessary to use operator overloading for an ORM at all. Maybe in some cases it might make sense.

The question is whether we want to provide a comparable experience to other languages or not.  What is desired depends on what other languages provide for a particular application area?

The ability to create abstractions is important for a language like D since that is supposed to be a primary feature.

On Tuesday, 5 January 2016 at 22:12:05 UTC, Mengu wrote:
> On Tuesday, 5 January 2016 at 08:26:16 UTC, Jacob Carlborg wrote:
>> [...]
>
> i love how things can become so complex in this community. i am a web developer so i am going to talk in terms of simplicity.
>
> as russel said, with SQLAlchemy (python library) operators are overloaded and we can do DBSession.query(User).filter(User.first_name == "Jacob", User.age > 27). this will generate the following query:
>
> "SELECT * FROM users u WHERE u.first_name = 'Jacob' AND u.age > 27" and will let the DB handle the rest.
>
> but as a web developer, i don't mind if i have to type User.where("first_name = ? AND age > 27", request.POST.get('name')). this will generate the same query above. i added the question mark to say the parameters should be escaped properly.
>
> guys, what we need is a DB abstraction supporting PostgreSQL, MySQL and other major database systems and we need it yesterday. let's not make things more complex than they are and build up this thing.
>
> p.s. this is not a reply to jacob, just his post was the one i clicked reply for. :-)

and while we were talking the talk, rust community rolled out something good called diesel. check it out at http://diesel.rs/.

we need tools that get things done. we do not need tools that makes things more complex than they already are.

On Saturday, 6 February 2016 at 00:14:08 UTC, Mengu wrote:
> and while we were talking the talk, rust community rolled out something good called diesel. check it out at http://diesel.rs/.
>
> we need tools that get things done. we do not need tools that makes things more complex than they already are.

I saw the examples on the site. In every case I prefer reading SQL instead of a complicated function chain with semantics I have yet to learn; SQL I already know.

A nice thing is the `less boilerplate` example. But I think they took a wrong approach by deriving the class from Queryable. I like D's approach better.

On Thursday, 31 December 2015 at 17:14:55 UTC, Piotrek wrote:
> The goal of this post is to measure the craziness of an idea to embed a database engine into the D language ;)
>
> I think about a database engine which would meet my three main requirements:
>   - integrated with D (ranges)
>   - ACID
>   - fast
>
> Since the days when I was working on financing data SW I become allergic to SQL. I though that NoSQL databases would fill the bill. Unfortunately they didn't. And I want to have an ability to write a code like this without too much effort:
>
>   struct Person
>   {
>    string name;
>    string surname;
>    ubyte age;
>    Address address;
>   }
>
>  DataBase db = new DataBase("file.db");
>  auto coll = db.collection!Person("NSA.Registry");
>  auto visitationList = coll.filter!(p => p.name == "James");
>  writeln (visitationList);
>
> And other things like updating and deleting from db. I think you get my point.
>
> So I started a PoC project based on SQLite design:
> https://github.com/PiotrekDlang/AirLock/blob/master/docs/database/design.md#architecture
>
> The PoC code: https://github.com/PiotrekDlang/AirLock/tree/master/src/database
>
> Can you please share your thoughts and experience on the topic? Has anyone tried similar things?
>
> Piotrek

I've scanned this thread, but haven't seen if any 'decisions' have been more, or if it is just more of the usual back-and-forth with nothing being decided.  However, I did have one (Ok two) questions.

1. Is there a GSOC project in here somewhere?
2. Who would want to mentor such a thing?

On Saturday, 6 February 2016 at 13:33:34 UTC, Craig Dillabaugh wrote:
clip
> I've scanned this thread, but haven't seen if any 'decisions' have been more, or if it is just more of the usual
>
have been more => have been made

On Saturday, 6 February 2016 at 00:14:08 UTC, Mengu wrote:
> and while we were talking the talk, rust community rolled out something good called diesel. check it out at http://diesel.rs/.
>
> we need tools that get things done. we do not need tools that makes things more complex than they already are.

Almost no one (including me) is interested in ORM for SQL. The point is ORM+SQL is limiting and sooner or later you fallback to SQL.

Additionally there is no critical mass for this kind of big project (combining all the SQL engines - good luck).

Andrei suggested a CTFE sql parser, so people who like SQL (not me) can benefit from the D metaprogramming power.

For the rest there is my proposal ;) : a language embedded DB. As far as I can tell none of the known PLes has this "killer" feature.

Piotrek

On Tuesday, 5 January 2016 at 04:19:01 UTC, Chris Wright wrote:
> You could equivalently have a string containing valid D code, accompanied by CTFE parsers that will determine which indices to use. This has typically been considered an antipattern. It tends to work poorly with refactoring tools, for instance, and there's an assumption that string literals are data and not code.

Would the D string tokens do?

BTW. Thanks for all your valuable comments. I really like that kind of critique.

> C#'s system of lambda expressions that you can access as expression trees keeps the benefits of writing everything in the same language.

I think I'm still not convinced to that approach (seems hacky). I agree with Walter in that matter (language changes, AST, overloading etc).

Especially, D is number one in meta-programming capabilities (among C++ and Rust) and nothing seems to change it in foreseeable future (https://users.rust-lang.org/t/rust-vs-dlang-i-want-more-experienced/4472/11)

Piotrek

On Saturday, 6 February 2016 at 13:41:03 UTC, Piotrek wrote:
> On Saturday, 6 February 2016 at 00:14:08 UTC, Mengu wrote:
>> and while we were talking the talk, rust community rolled out something good called diesel. check it out at http://diesel.rs/.
>>
>> we need tools that get things done. we do not need tools that makes things more complex than they already are.
>
> Almost no one (including me) is interested in ORM for SQL. The point is ORM+SQL is limiting and sooner or later you fallback to SQL.

A good ORM-like interface is mandatory for working with NoSQL databases...