On Wednesday, 4 February 2015 at 16:46:19 UTC, Andrei
Alexandrescu wrote:
On 2/1/15 8:00 PM, Vadim Lopatin wrote:
I would like to propose Java way for implementation of DB
access (JDBC -
Java DataBase Connectors).
[snip]
I think we should use ODBC as the foundation and build neat
D-ish stuff
On 2/1/15 8:00 PM, Vadim Lopatin wrote:
I would like to propose Java way for implementation of DB access (JDBC -
Java DataBase Connectors).
[snip]
I think we should use ODBC as the foundation and build neat D-ish stuff
on top of it. It's a mature technology with tried and tested drivers
avail
On Tuesday, 3 February 2015 at 16:42:24 UTC, FG wrote:
A misfeature? If the ORM only allowed SELECT *, it wouldn't be
of much use with records containing blobs or big amounts of
other data. If the object was retrieved only for read and to
update a few fields, pulling all columns would be very w
On Tuesday, 3 February 2015 at 15:20:41 UTC, Vadim Lopatin wrote:
On Tuesday, 3 February 2015 at 14:41:02 UTC, Vadim Lopatin
wrote:
On Tuesday, 3 February 2015 at 10:49:07 UTC, Robert burner
IMO writing:
foreach(it; db.select("...")) {
}
is epic. you have entered std.(range|algorithm) land.
On Tuesday, 3 February 2015 at 19:54:52 UTC, Szymon Gatner wrote:
This should have happened from the start with logging library
too (should have been based on boost.log) and in this case one
should look into SOCI (http://soci.sourceforge.net/) and not
Java versions.
https://github.com/SOCI/so
On Tuesday, 3 February 2015 at 19:54:52 UTC, Szymon Gatner wrote:
On Monday, 2 February 2015 at 04:00:31 UTC, Vadim Lopatin wrote:
I would like to propose Java way for implementation of DB
access (JDBC - Java DataBase Connectors).
Please no. If anything, *any* new library for D should be bas
On Monday, 2 February 2015 at 04:00:31 UTC, Vadim Lopatin wrote:
I would like to propose Java way for implementation of DB
access (JDBC - Java DataBase Connectors).
Please no. If anything, *any* new library for D should be based
on C++ version and then make it nicer with D features. Basing
On 2015-02-03 17:42, FG wrote:
A misfeature? If the ORM only allowed SELECT *, it wouldn't be of much
use with records containing blobs or big amounts of other data. If the
object was retrieved only for read and to update a few fields, pulling
all columns would be very wasteful.
Martin Nowak s
Ok than it is ok :)
- Původní zpráva -
Od:"Vadim Lopatin via Digitalmars-d"
Odesláno:3. 2. 2015 18:00
Komu:"digitalmars-d@puremagic.com"
Předmět:Re: H1 2015 - db access support in Phobos
On Tuesday, 3 February 2015 at 15:30:42 UTC, Daniel Kozák wrote:
> V Tu
For blobs or other unneeded data you can setup column as lazy fetch. What I
mean is situation when you have object in inconsistent state.
- Původní zpráva -
Od:"FG via Digitalmars-d"
Odesláno:3. 2. 2015 17:45
Komu:"digitalmars-d@puremagic.com"
Předmět:Re: H1 2015
On Tuesday, 3 February 2015 at 15:30:42 UTC, Daniel Kozák wrote:
V Tue, 03 Feb 2015 15:20:40 +
Vadim Lopatin via Digitalmars-d
napsáno:
On Tuesday, 3 February 2015 at 14:41:02 UTC, Vadim Lopatin
wrote:
> On Tuesday, 3 February 2015 at 10:49:07 UTC, Robert burner
>> IMO writing:
>>
>> fo
On 2015-02-03 at 16:30, Daniel Kozák via Digitalmars-d wrote:
V Tue, 03 Feb 2015 15:20:40 +
Vadim Lopatin via Digitalmars-d napsáno:
Update in v0.2.19: you can specify field list for select
writeln("reading all user table rows, but fetching only id
and name (you will see default valu
On Tuesday, 3 February 2015 at 14:03:22 UTC, Kagamin wrote:
The database client library or the database itself in case of
sqlite, i.e. code you link with. Dependency also means you
should get it somewhere, possibly compiling with dmc.
If only interfaces included into Phobos, it's not a problem
nice!
get it into phobos or vibe
In my experience such optimizations are usually needed only for
reading, so the query may return a plain tuple instead of true
mapped object. Well, this can depend on whether you have an ORM
container.
V Tue, 03 Feb 2015 15:20:40 +
Vadim Lopatin via Digitalmars-d napsáno:
> On Tuesday, 3 February 2015 at 14:41:02 UTC, Vadim Lopatin wrote:
> > On Tuesday, 3 February 2015 at 10:49:07 UTC, Robert burner
> >> IMO writing:
> >>
> >> foreach(it; db.select("...")) {
> >> }
> >>
> >> is epic. you h
On Tuesday, 3 February 2015 at 14:41:02 UTC, Vadim Lopatin wrote:
On Tuesday, 3 February 2015 at 10:49:07 UTC, Robert burner
IMO writing:
foreach(it; db.select("...")) {
}
is epic. you have entered std.(range|algorithm) land.
Implemented in v0.2.17 for select.
test:
auto ds = new Conne
On Tuesday, 3 February 2015 at 10:49:07 UTC, Robert burner
Schadek wrote:
On Tuesday, 3 February 2015 at 10:33:25 UTC, Vadim Lopatin
wrote:
ORM operations are not a simple single query/statement.
They often use several queries to load dependent objects.
make it an output range
Of course, s
The database client library or the database itself in case of
sqlite, i.e. code you link with. Dependency also means you should
get it somewhere, possibly compiling with dmc.
On Tuesday, 3 February 2015 at 12:06:25 UTC, Kagamin wrote:
I see problems with licensing and external dependencies.
License on API? (like Sun sued Google for implementation of Java
API?)
Or on third party libraries used by DB drivers.
I see problems with licensing and external dependencies.
On Tuesday, 3 February 2015 at 10:33:25 UTC, Vadim Lopatin wrote:
ORM operations are not a simple single query/statement.
They often use several queries to load dependent objects.
make it an output range
Of course, some CTFE/UDAs may be used for generation of field
list, but it is not very
On Tuesday, 3 February 2015 at 09:16:14 UTC, Robert burner
Schadek wrote:
But for such high level DB library must be based on some lower
level DB API (connector).
Like JDBC for JPA or Hibernate in Java.
really, does it? there is no need for an abstraction layer. you
can have functions generat
But for such high level DB library must be based on some lower
level DB API (connector).
Like JDBC for JPA or Hibernate in Java.
really, does it? there is no need for an abstraction layer. you
can have functions generate the correct source for mysql, sqlite,
you name it. e.g. just generate th
On Tuesday, 3 February 2015 at 08:37:04 UTC, Robert burner
Schadek wrote:
IMO the java way is to uncreative. We have UDA, CTFE and string
mixins anything short of perfect SQL generated at compile time
without anything else than UDA annotation to my structs is an
epic lose for D. I mean, who wan
On Tuesday, 3 February 2015 at 08:23:56 UTC, Daniel Kozak wrote:
On Monday, 2 February 2015 at 04:00:31 UTC, Vadim Lopatin wrote:
I would like to propose Java way for implementation of DB
access (JDBC - Java DataBase Connectors).
Standard library must contain only
* set of interfaces for unifo
IMO the java way is to uncreative. We have UDA, CTFE and string
mixins anything short of perfect SQL generated at compile time
without anything else than UDA annotation to my structs is an
epic lose for D. I mean, who wants to write string statements
when the lib can generate them for you. For
On Monday, 2 February 2015 at 04:00:31 UTC, Vadim Lopatin wrote:
I would like to propose Java way for implementation of DB
access (JDBC - Java DataBase Connectors).
Standard library must contain only
* set of interfaces for uniform DB access
* Connection - can create Statement or PreparedSt
On Monday, 2 February 2015 at 04:00:31 UTC, Vadim Lopatin wrote:
I would like to propose Java way for implementation of DB
access (JDBC - Java DataBase Connectors).
Standard library must contain only
* set of interfaces for uniform DB access
* Connection - can create Statement or PreparedSt
On Monday, 2 February 2015 at 18:00:28 UTC, AndyC wrote:
On Monday, 2 February 2015 at 04:00:31 UTC, Vadim Lopatin wrote:
I would like to propose Java way for implementation of DB
access (JDBC - Java DataBase Connectors).
Standard library must contain only
* set of interfaces for uniform DB ac
On Monday, 2 February 2015 at 04:00:31 UTC, Vadim Lopatin wrote:
I would like to propose Java way for implementation of DB
access (JDBC - Java DataBase Connectors).
Standard library must contain only
* set of interfaces for uniform DB access
* Connection - can create Statement or PreparedSt
I would like to propose Java way for implementation of DB access
(JDBC - Java DataBase Connectors).
Standard library must contain only
* set of interfaces for uniform DB access
* Connection - can create Statement or PreparedStatement,
control transactions
* Statement - can run update o
32 matches
Mail list logo
