On Saturday, 6 February 2016 at 14:04:42 UTC, Ola Fosheim Grøstad wrote:
> A good ORM-like interface is mandatory for working with NoSQL databases...

Fortunately, I don't plan to work with so called NoSQL databases...

BTW. Take a look at the example from the PoC code and check what works currently (i.e. passing unit tests)

https://github.com/PiotrekDlang/AirLock/blob/master/docs/database/design.md#example

Piotrek

On Saturday, 6 February 2016 at 13:41:03 UTC, Piotrek wrote:
>
> 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

SAS does, and has for quite a few decades now. Its a pretty big corporate language used for statistics and analysis. It does work exceptionally well, easily handling well over 100M records within a single table. They implement a table per file (sas7bdat). That said, the binary table format is proprietary, and while there have been attempts to reverse engineer it none have been completely successful.

On Sat, 06 Feb 2016 13:41:03 +0000, 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.

You mean, a high-level query language abstracting across multiple databases, expressed in terms of my object model rather than physical tables. You're talking about HQL, not Hibernate as a whole.

Nobody wants to write manual serialization and deserialization code. Not when there's a reliable, low-cost alternative. And if I could just write my object model and have an automated system create my database tables and upgrade scripts for me, that would be cool too.

> The point is
> ORM+SQL is limiting and sooner or later you fallback to SQL.

The HQL I recall would be bad for reporting and aggregation, but since I never needed that, perhaps I just didn't find the relevant options and syntax.

I find HQL slightly nicer to work with than SQL, but since the databases themselves aren't speaking it, it's not so handy. I found one query that I needed where HQL could do it in two minutes and hand-written SQL could do it in fifty milliseconds. That's rare, but it does happen.

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.
>

I wouldn't say almost no one.  I know Sql Alchemy is very popular and used by a lot of ppl. Ive used and not used ORMs on numerous projects and sometimes they make sense and sometimes they do not.  I agree its not needed but alot of these tools are used by average developers and not having them isn't going to help D.   Not that we don't need them but when ppl say "Well I like D but find there are missing libraries I want"  A decent ORM would prolly be one of them.  Basically if Rust continues to get these libraries and they are decent then they will def attract more ppl to the language instead of them possibly coming to D if that is important which I know has been brought up before and I think projects and tools like these with further attract ppl.

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.
>
> 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

i don't mind if it's an ORM or something else. my point was that instead of complaining about stuff, we need a safe, stable and extendable database library supporting sqlite, mysql, postgresql, mssql and oracle dbs and we need it like yesterday. nothing fancy. people can get creative and fancy over that standard api and users get to choose.

On Monday, 8 February 2016 at 13:36:09 UTC, Mengu wrote:
>
> i don't mind if it's an ORM or something else. my point was that instead of complaining about stuff, we need a safe, stable and extendable database library supporting sqlite, mysql, postgresql, mssql and oracle dbs and we need it like yesterday. nothing fancy. people can get creative and fancy over that standard api and users get to choose.

Something like JDBC on D ... --> https://code.dlang.org/packages/ddbc