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
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
On Sat, 06 Feb 2016 13:41:03 +, 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
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
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
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
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
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
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
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
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 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,
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
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
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,
On Mon, 2016-01-04 at 12:07 -0800, Walter Bright via Digitalmars-d
wrote:
>
[…]
> I'm surprised you'd ask. I thought this was well known.
>
> 1. ugly as hell
For you perhaps, others have different opinions. I like it.
> 2. not exception safe
Indeed. but then most code is not exception safe
On 1/9/2016 2:49 AM, Russel Winder via Digitalmars-d wrote:
The D code as presented is clearly simpler and easy to read. However
the D grammar is a string and not code so the anticipation is that
errors in the C++ code would be easier to find and correct. I guess the
question here is how good
On Thu, 2016-01-07 at 15:32 -0500, Andrei Alexandrescu via Digitalmars-
d wrote:
> On 01/07/2016 02:02 PM, Russel Winder via Digitalmars-d wrote:
[…]
>
> Got it, thanks. I took a look at a familiar topic - json grammars.
>
> I just googled `boost spirit json` and followed through the top
>
On 1/9/2016 3:02 AM, Russel Winder via Digitalmars-d wrote:
[...]
And also generally bad architecting of I/O in applications.
These problems have persisted since the genesis of iostreams. The problems do
not exist in the way other modern languages do I/O. Iostreams was a great idea
in 1985,
On 1/9/16 5:49 AM, Russel Winder via Digitalmars-d wrote:
On Thu, 2016-01-07 at 15:32 -0500, Andrei Alexandrescu via Digitalmars-
d wrote:
On 01/07/2016 02:02 PM, Russel Winder via Digitalmars-d wrote:
[…]
Got it, thanks. I took a look at a familiar topic - json grammars.
I just googled
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
On Saturday, 9 January 2016 at 11:02:46 UTC, Russel Winder wrote:
There is a difference always between what you can do and what
you should do. The language should not be fascist in stopping
all things not deemed the one true way by the language
designers. To do so stops serendipitous
On Mon, 2016-01-04 at 15:39 -0500, Andrei Alexandrescu via Digitalmars-
d wrote:
> On 01/04/2016 01:28 PM, Russel Winder via Digitalmars-d wrote:
> > Rusts macros show it can be done well.
>
> Do you have a few examples handy? Thanks. -- Andrei
Will do but it may be next week. Sorry, but medical
On Monday, 4 January 2016 at 09:44:35 UTC, Walter Bright wrote:
On 1/1/2016 3:33 AM, Russel Winder via Digitalmars-d wrote:
Or alternative 4, fix D so that proper operator definition can
be
achieved.
The way D's operator overloading is designed is not a mistake.
It's limitations are a
On 01/07/2016 02:02 PM, Russel Winder via Digitalmars-d wrote:
On Mon, 2016-01-04 at 15:38 -0500, Andrei Alexandrescu via Digitalmars-
d wrote:
[…]
I don't think regexen were the point as much as an example. What is
Boost.Sprint? I haven't heard of it, and can't find it. Thanks!
As others
On Mon, 2016-01-04 at 15:38 -0500, Andrei Alexandrescu via Digitalmars-
d wrote:
>
[…]
> I don't think regexen were the point as much as an example. What is
> Boost.Sprint? I haven't heard of it, and can't find it. Thanks!
As others mentioned, it was a mis-type, it is Boost.Spirit.
On Tuesday, 5 January 2016 at 22:12:05 UTC, Mengu wrote:
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.
I'm personally a fan of dplyr
On 2016-01-05 18:32, Chris Wright wrote:
Which some people call a DSL, and DSLs were, I understand, something we
were trying to avoid. You get far less readability than you do with plain
D or a SQL string.
The above is plain D. Not sure what you're referring to. And a DSL is
usually used to
On Tuesday, 5 January 2016 at 22:12:05 UTC, Mengu wrote:
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
On Monday, 4 January 2016 at 17:36:20 UTC, Piotrek wrote:
Thanks! So at least one more soul believing that D can approach
the SQL expressiveness in db domain.
Cheers
Piotrek
Some time ago I had the same idea as yours. IMHO, no D to SQL is
really needed for this, and the same goes for
On 2016-01-05 05:16, Chris Wright wrote:
Not proposing language changes was an intentional feature, not a mistake.
Then you obviously can't use the operators. You would have to fall back
to methods:
Person.where!(e => e.name.eq("John"));
--
/Jacob Carlborg
On Tue, 05 Jan 2016 09:26:16 +0100, Jacob Carlborg wrote:
> On 2016-01-05 05:16, Chris Wright wrote:
>
>> Not proposing language changes was an intentional feature, not a
>> mistake.
>
> Then you obviously can't use the operators. You would have to fall back
> to methods:
>
> Person.where!(e
On Tuesday, 5 January 2016 at 08:26:16 UTC, Jacob Carlborg wrote:
On 2016-01-05 05:16, Chris Wright wrote:
Not proposing language changes was an intentional feature, not
a mistake.
Then you obviously can't use the operators. You would have to
fall back to methods:
Person.where!(e =>
On Tuesday, 5 January 2016 at 22:12:05 UTC, Mengu wrote:
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.
What is needed isn't a DB
On Monday, 4 January 2016 at 20:38:46 UTC, Andrei Alexandrescu
wrote:
On 01/04/2016 01:25 PM, Russel Winder via Digitalmars-d wrote:
[snip]
What is Boost.Sprint? I haven't heard of it, and can't find it.
Thanks! -- Andrei
I think he miss-typed or miss-remembered. It is Boost.Spirit.
On 1/4/2016 10:25 AM, Russel Winder via Digitalmars-d wrote:
On Mon, 2016-01-04 at 01:44 -0800, Walter Bright via Digitalmars-d
wrote:
1. Make doing C++ style iostreams hard.
What is the problem with having the << and >> operators do input
output. Very object-oriented.
I'm surprised you'd
On Monday, 4 January 2016 at 18:28:15 UTC, Russel Winder wrote:
On Mon, 2016-01-04 at 01:45 -0800, Walter Bright via
Digitalmars-d wrote:
On 1/3/2016 11:40 PM, Jacob Carlborg wrote:
> There's of course AST macros as well, which have many other
> good
> use cases.
> Unfortunately you don't
On 01/04/2016 02:50 PM, rsw0x wrote:
D did wonders in making template metaprogramming usable compared to C++,
but sometimes it feels like trying to pound nails in with a screwdriver.
Do you have examples of that awkwardness happening? Is it suitable to
supplement those with CTFE? -- Andrei
On 01/04/2016 01:28 PM, Russel Winder via Digitalmars-d wrote:
Rusts macros show it can be done well.
Do you have a few examples handy? Thanks. -- Andrei
On 01/04/2016 01:25 PM, Russel Winder via Digitalmars-d wrote:
What is the problem with having the << and >> operators do input
output. Very object-oriented.
What is the connection between using shift operators for I/O and object
orientation?
But it would be D. Boost.Sprint code may look
On 1/3/2016 11:40 PM, Jacob Carlborg wrote:
There's of course AST macros as well, which have many other good use cases.
Unfortunately you don't like those either :(
Neither Andrei nor I have changed our minds on that one.
On 1/1/2016 3:33 AM, Russel Winder via Digitalmars-d wrote:
Or alternative 4, fix D so that proper operator definition can be
achieved.
The way D's operator overloading is designed is not a mistake. It's limitations
are a feature, not a bug. It was deliberately set up to:
1. Make doing C++
On Monday, 4 January 2016 at 07:48:14 UTC, Jacob Carlborg wrote:
Perhaps I'm missing something obvious but there are several
problems with this:
1. What happens when you use more than one query for the same
table at the same scope? In the above case, "Person" is already
defined the second
On Monday, 4 January 2016 at 00:49:29 UTC, Andrei Alexandrescu
wrote:
Second, ET as a mechanism for SQL interface has other inherent
limitations. Consider the "LIKE" operator in SQL, which has no
ET equivalent in C++ with similar syntax, and no direct
like(Person.Name,"peter%")
Person.Name
On 1/1/2016 3:37 AM, Russel Winder via Digitalmars-d wrote:
On Fri, 2016-01-01 at 10:45 +, Ola Fosheim Grøstad via Digitalmars-
d wrote:
In D1 Walter made a point about restricting operator overloading
to discourage reuse of operators. In D2 there are many ways to
Java also went the route
On 1/4/2016 2:34 AM, Ola Fosheim Grøstad wrote:
On Monday, 4 January 2016 at 09:44:35 UTC, Walter Bright wrote:
My not-so-humble opinion is these sorts of DSLs are technical demonstrations,
but not useful nor desirable tools.
Well, this is wrong. They are desirable and work with tooling,
On Monday, 4 January 2016 at 09:44:35 UTC, Walter Bright wrote:
My not-so-humble opinion is these sorts of DSLs are technical
demonstrations, but not useful nor desirable tools.
Well, this is wrong. They are desirable and work with tooling,
editors, code completion etc. And also allow user
On 2016-01-04 00:50, Andrei Alexandrescu wrote:
This may in fact be good signal that an approach based on expression
templates is not the most appropriate for D. -- Andrei
This whole thread has already discussed and showed that D operator
overloading is lacking in terms of expression
On 2016-01-02 21:47, Chris Wright wrote:
So you want to create the following query:
people.filter!(x => x.surname == "Slughorn");
And you've got ten million people in the collection, and you want this
query to finish soonish. So you need to use an index. But a full index
scan isn't so
On Monday, 4 January 2016 at 07:55:53 UTC, Jacob Carlborg wrote:
On 2016-01-02 21:47, Chris Wright wrote:
So you want to create the following query:
people.filter!(x => x.surname == "Slughorn");
And you've got ten million people in the collection, and you
want this
query to finish
What is Boost.Sprint? I haven't heard of it, and can't find it.
Thanks! -- Andrei
I believe he meant Boost Spirit
http://www.boost.org/doc/libs/1_60_0/libs/spirit/doc/html/spirit/introduction.html
Zz
On Monday, 4 January 2016 at 20:07:55 UTC, Walter Bright wrote:
On 1/4/2016 10:25 AM, Russel Winder via Digitalmars-d wrote:
It is important that this works. But it should be possible to
create an
operator algebra for any type: arithmetic types are a very
small subset
of types used in
FWIW, were I proposing a "Database Engine for D" I'd be proposing a
B+Tree that was restricted to storing explicit data (no pointers or
other indirection...including strings, you'd need to specify fixed size
arrays of char, wchar, or dchar). There would be one "type"/file, and
the "type"
On Mon, 04 Jan 2016 08:55:53 +0100, Jacob Carlborg wrote:
> If D had better operator overloading or supported AST macros, opEquals
> would not return true. It would return a new proxy that overloads the ||
> operator. The rest of the post falls apart from this mistake.
Not proposing language
On Mon, 04 Jan 2016 16:59:47 +, Piotrek wrote:
> SQL is no magic.
True. 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
On 2016-01-04 10:44, Walter Bright wrote:
So, what does D do?
http://dlang.org/phobos/std_regex.html
D enables CTFE to write a PROPER compile time regex language, with
correct regex grammar, correct regex tokens, regex-specific error
messages, etc. And it works great! It's not a hack,
On Mon, 2016-01-04 at 08:29 +, rsw0x via Digitalmars-d wrote:
>
[…]
> compiler plugins like Rust to enable AST macros could fix this
> but walter and andrei seem extremely opposed to any form of
> macros so we end up with ugly heavily templated ugly band-aids
Rust may have macros, in fact
On Monday, 4 January 2016 at 11:19:38 UTC, Walter Bright wrote:
ou didn't address my points. Have you used C++ ETs for
production? They fall apart in real world use for the reasons I
mentioned. It's one thing to read a paper about something, and
another to use it for something larger than will
On 2016-01-04 12:14, Sebastiaan Koppe wrote:
But then you are back to square one with regards to queries.
If you can't use the host language, i.e. Person.where(e => e.name ==
"John");, what's the point of inventing a new DSL? Why not just use SQL
if the DSL needs to be in a string anyway.
On Monday, 4 January 2016 at 12:28:47 UTC, Russel Winder wrote:
I must now try creating a D version of the
pytest.mark.parametrize decorator – unless someone already has
and I have just missed it.
I quick look at pytest.mark.parametrize suggests it could be
implemented with UDAs and a
On 01/04/2016 01:49 AM, rumbu wrote:
On Monday, 4 January 2016 at 00:49:29 UTC, Andrei Alexandrescu wrote:
Second, ET as a mechanism for SQL interface has other inherent
limitations. Consider the "LIKE" operator in SQL, which has no ET
equivalent in C++ with similar syntax, and no direct
On 01/04/2016 08:09 AM, John Colvin wrote:
On Monday, 4 January 2016 at 12:28:47 UTC, Russel Winder wrote:
I must now try creating a D version of the pytest.mark.parametrize
decorator – unless someone already has and I have just missed it.
I quick look at pytest.mark.parametrize suggests it
On 01/04/2016 07:39 AM, Jacob Carlborg wrote:
If you can't use the host language, i.e. Person.where(e => e.name ==
"John");, what's the point of inventing a new DSL? Why not just use SQL
if the DSL needs to be in a string anyway.
I agree. A CTFE SQL parser with automatic variable binding would
On Saturday, 2 January 2016 at 20:47:37 UTC, Chris Wright wrote:
So you want to create the following query:
people.filter!(x => x.surname == "Slughorn");
And you've got ten million people in the collection, and you
want this query to finish soonish. So you need to use an index.
But a full
On Sunday, 3 January 2016 at 19:48:42 UTC, Abdulhaq wrote:
My two pence, if you want it to be fast then it must have a
good implementation of indices. Your filter functions should
not actually start collecting real records, but instead should
simply change the way that the cursor traverses the
On Monday, 4 January 2016 at 07:59:40 UTC, Jacob Carlborg wrote:
On 2016-01-04 00:50, Andrei Alexandrescu wrote:
This may in fact be good signal that an approach based on
expression
templates is not the most appropriate for D. -- Andrei
This whole thread has already discussed and showed
On Sunday, 3 January 2016 at 23:22:17 UTC, Jakob Jenkov wrote:
You could just target your database at data analysis. Then you
don't need to care about ACID, transactions etc. Just load all
the data into memory, and start analyzing it.
Also, you'd typically be scanning over large parts of the
On Mon, 2016-01-04 at 13:09 +, John Colvin via Digitalmars-d wrote:
>
[…]
> not sure when I'd use that though...
At a trivial level that nonetheless leads to functionality that can be
used more sensibly, think of testing factorial. You want property-based
testing, but also you want a (well
On Mon, 2016-01-04 at 01:44 -0800, Walter Bright via Digitalmars-d
wrote:
> On 1/1/2016 3:33 AM, Russel Winder via Digitalmars-d wrote:
> > Or alternative 4, fix D so that proper operator definition can be
> > achieved.
>
> The way D's operator overloading is designed is not a mistake. It's
>
On Mon, 2016-01-04 at 01:45 -0800, Walter Bright via Digitalmars-d
wrote:
> On 1/3/2016 11:40 PM, Jacob Carlborg wrote:
> > There's of course AST macros as well, which have many other good
> > use cases.
> > Unfortunately you don't like those either :(
>
> Neither Andrei nor I have changed our
On 1/2/16 7:23 AM, Jacob Carlborg wrote:
On 2016-01-01 11:45, Ola Fosheim Grøstad wrote:
In D1 Walter made a point about restricting operator overloading to
discourage reuse of operators. In D2 there are many ways to create your
own weird syntax, but Walter is locked on his D1 position, even
You could just target your database at data analysis. Then you
don't need to care about ACID, transactions etc. Just load all
the data into memory, and start analyzing it.
Also, you'd typically be scanning over large parts of the data
set for each query, so you may not need to support a full
On 1/1/16 6:30 AM, Russel Winder via Digitalmars-d wrote:
On Fri, 2016-01-01 at 10:40 +, Kapps via Digitalmars-d wrote:
[…]
Someone else can explain better / more correctly than me, but I
believe the issue lies with opCmp and opEquals. You can make
expressions like p.Name.equals("James")
On 1/2/16 3:47 PM, Chris Wright wrote:
On Sat, 02 Jan 2016 16:40:16 +, Piotrek wrote:
On Friday, 1 January 2016 at 10:00:43 UTC, Kapps wrote:
This example shows the difficulty of doing this in D. You can't really
have something like `p.Name == "James"`, or `p.Age < 21`
translate to SQL
On 2016-01-03 17:45, Sebastiaan Koppe wrote:
Suppose you have this:
mixin(db(`
Entity Person
Fields
name -> string
age -> integer
Query
byAge(a -> integer) -> age == a
`));
which generates something like this:
struct Person
{
string name;
int age
}
auto
On Monday, 4 January 2016 at 00:49:29 UTC, Andrei Alexandrescu
wrote:
Second, ET as a mechanism for SQL interface has other inherent
limitations. Consider the "LIKE" operator in SQL, which has no
ET equivalent in C++ with similar syntax, and no direct
equivalent in LINQ. That doesn't mean
On 2016-01-04 01:50, Andrei Alexandrescu wrote:
Binding D variables to SQL expressions also comes to mind. -- Andrei
You have also been pushing a lot for ranges, which I think is good. I
would much rather like to view a table as a range, but the algorithms
would be preform in the database
On 2016-01-04 01:49, Andrei Alexandrescu wrote:
Second, ET as a mechanism for SQL interface has other inherent
limitations. Consider the "LIKE" operator in SQL, which has no ET
equivalent in C++ with similar syntax, and no direct equivalent in LINQ.
That doesn't mean the respective languages
On 2016-01-02 21:48, Sebastiaan Koppe wrote:
I meant that you generate the struct from the DSL, and then migration
code from that struct.
I don't think I understand, it seems complicated.
--
/Jacob Carlborg
On Sunday, 3 January 2016 at 14:32:48 UTC, Jacob Carlborg wrote:
On 2016-01-02 21:48, Sebastiaan Koppe wrote:
I meant that you generate the struct from the DSL, and then
migration
code from that struct.
I don't think I understand, it seems complicated.
Suppose you have this:
mixin(db(`
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
On Saturday, 2 January 2016 at 12:23:30 UTC, Jacob Carlborg wrote:
The core developers are making a big deal out of being able to
have DSL's as string literals and process them at compile time.
They have probably never done professional work with an ORM...
Nobody wants that.
On Friday, 1 January 2016 at 11:37:40 UTC, Russel Winder wrote:
(*) Arguably Scala takes this too far.
Btw, regarding operator overloading:
Your comment about Scala made me think about the proposals for
Algol which allowed the language to be heavily extended with even
custom operator
On 2016-01-01 11:45, Ola Fosheim Grøstad wrote:
In D1 Walter made a point about restricting operator overloading to
discourage reuse of operators. In D2 there are many ways to create your
own weird syntax, but Walter is locked on his D1 position, even though
it makes little sense in D2.
This
On 2016-01-01 12:33, Russel Winder via Digitalmars-d wrote:
On Fri, 2016-01-01 at 11:03 +, Jacob Carlborg via Digitalmars-d
wrote:
[…]
That's exactly the problem. See an issue reported [1] and a
related thread [2]. AST macros could solve the problem as well
[3] (and many other problems).
On Friday, 1 January 2016 at 04:20:19 UTC, tcak wrote:
You know someone needs to maintain all that code base
continuously. When SQLite is a separate project, it has its own
developers and we just bind to its library; it is same for
other DBs. Your proposal is nice, but creating another
On Saturday, 2 January 2016 at 12:23:30 UTC, Jacob Carlborg wrote:
The core developers are making a big deal out of being able to
have DSL's as string literals and process them at compile time.
Although that's kind of pointless with SQL, since one still
needs to send to string to the database
On Friday, 1 January 2016 at 01:34:53 UTC, Rikki Cattermole wrote:
You've just introduced two topics.
The first is a database engine, abstracting away the drivers.
And second an ORM.
And maybe even an object-oriented database management system to
some extent. OTOH, I removed SQL from the
On Friday, 1 January 2016 at 10:00:43 UTC, Kapps wrote:
This example shows the difficulty of doing this in D. You can't
really have something like `p.Name == "James"`, or `p.Age < 21`
translate to SQL properly without language changes, which I
believe Walter or Andrei were against. This has
On 2016-01-02 13:55, Ola Fosheim Grøstad wrote:
They have probably never done professional work with an ORM...
Nobody wants that.
Exactly, but tell them ;)
--
/Jacob Carlborg
On 2016-01-02 19:37, Sebastiaan Koppe wrote:
Well, you can also generate the structs and specific serialization code.
And depending on how advanced your dsl you can also auto generate
database migration code. There are propably tons of other stuff you can
do with it.
All in all much better
On Saturday, 2 January 2016 at 19:48:26 UTC, Jacob Carlborg wrote:
I would rather to the opposite. Generate the necessary SQL for
a migration based on a struct, not the other way around.
I meant that you generate the struct from the DSL, and then
migration code from that struct.
On Sat, 02 Jan 2016 16:40:16 +, Piotrek wrote:
> On Friday, 1 January 2016 at 10:00:43 UTC, Kapps wrote:
>
>> This example shows the difficulty of doing this in D. You can't really
>> have something like `p.Name == "James"`, or `p.Age < 21`
>> translate to SQL properly without language
On Saturday, 2 January 2016 at 19:46:48 UTC, Jacob Carlborg wrote:
On 2016-01-02 13:55, Ola Fosheim Grøstad wrote:
They have probably never done professional work with an ORM...
Nobody wants that.
Exactly, but tell them ;)
I did:
On Friday, 1 January 2016 at 10:26:14 UTC, Russel Winder wrote:
Why does it need language changes?
Having the ability to have an internal DSL instead of SQL
string fiddling is one of the major wins for SQLAlchemy. If it
can be done in Python why can't it be done in D?
In D1 Walter made a
On Friday, 1 January 2016 at 10:26:14 UTC, Russel Winder wrote:
On Fri, 2016-01-01 at 10:00 +, Kapps via Digitalmars-d
wrote:
On Thursday, 31 December 2015 at 17:14:55 UTC, Piotrek wrote:
>
> struct Person
> {
> string name;
> string surname;
> ubyte age;
> Address
On Friday, 1 January 2016 at 10:40:59 UTC, Kapps wrote:
Someone else can explain better / more correctly than me, but I
believe the issue lies with opCmp and opEquals. You can make
expressions like p.Name.equals("James") work (I believe using
opDispatch), but because all you have is opEquals,
On Fri, 2016-01-01 at 10:00 +, Kapps via Digitalmars-d wrote:
> On Thursday, 31 December 2015 at 17:14:55 UTC, Piotrek wrote:
> >
> > struct Person
> > {
> > string name;
> > string surname;
> > ubyte age;
> > Address address;
> > }
> >
> > DataBase db = new
On Fri, 2016-01-01 at 11:03 +, Jacob Carlborg via Digitalmars-d
wrote:
>
[…]
> That's exactly the problem. See an issue reported [1] and a
> related thread [2]. AST macros could solve the problem as well
> [3] (and many other problems).
>
> [1]
On Thursday, 31 December 2015 at 17:14:55 UTC, Piotrek wrote:
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
1 - 100 of 105 matches
Mail list logo
