www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - HibernateD and DDBC - ORM and DB abstraction layer for D

reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
Hello!

I've started implemetation of ORM in D, with annotations and 
interfaces similar to Hibernate.

As DB abstraction layer I wrote DDBC - library with interface 
similar to JDBC. Only MySQL driver is implemented. PostgreSQL - 
in progress.

Project is hosted on SourceForge: 
https://sourceforge.net/p/hibernated/wiki/HibernateD/ License is 
Boost

HibernateD collects metadata from classes annotated with 
Hibernate-like UDAs.

Simple properties of supported: you can annotate fields, D 
properties or getter+setter pairs in your class, of types string, 
byte, short, int, long, ubyte, ushort, uint, ulong, byte[], 
ubyte[], DateTime, Date, TimeOfDay; for non-nullable types to 
support Null value use Nullable! template.

 Embedded entities supported - you can embed properties from 
 Embeddable object to  Entity's table.

 OneToOne,  OneToMany,  ManyToOne,  ManyToMany relations are 
supported. You can use Lazy! and LazyCollection! to support lazy 
loading of aggregates.

You can query DB using subset of HQL (Hibernate Query Language).

Look at project wiki and unittests for more info.
Apr 03 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 03 Apr 2013 16:28:36 +0200
"Vadim Lopatin" <coolreader.org gmail.com> wrote:


 Hello!
 
 I've started implemetation of ORM in D, with annotations and 
 interfaces similar to Hibernate.
 
 As DB abstraction layer I wrote DDBC - library with interface 
 similar to JDBC. Only MySQL driver is implemented. PostgreSQL - 
 in progress.
 
 Project is hosted on SourceForge: 
 https://sourceforge.net/p/hibernated/wiki/HibernateD/ License is 
 Boost
 
 HibernateD collects metadata from classes annotated with 
 Hibernate-like UDAs.
 
 Simple properties of supported: you can annotate fields, D 
 properties or getter+setter pairs in your class, of types string, 
 byte, short, int, long, ubyte, ushort, uint, ulong, byte[], 
 ubyte[], DateTime, Date, TimeOfDay; for non-nullable types to 
 support Null value use Nullable! template.
 
  Embedded entities supported - you can embed properties from 
  Embeddable object to  Entity's table.
 
  OneToOne,  OneToMany,  ManyToOne,  ManyToMany relations are 
 supported. You can use Lazy! and LazyCollection! to support lazy 
 loading of aggregates.
 
 You can query DB using subset of HQL (Hibernate Query Language).
 
 Look at project wiki and unittests for more info.
 


Sounds cool.

Can it be used with Vibe.d's system of asynchronous
connections? If not, then perhaps a backend for mysql-native
<https://github.com/rejectedsoftware/mysql-native/> could be added?
Apr 03 2013
parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
 Sounds cool.

 Can it be used with Vibe.d's system of asynchronous
 connections? If not, then perhaps a backend for mysql-native
 <https://github.com/rejectedsoftware/mysql-native/> could be 
 added?


Actually I'm using mysqln as backend. But I patched it, removing 
vibe dependancies. (Vibe connection replaced with standard one).
Apr 03 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 03 Apr 2013 18:54:13 +0200
"Vadim Lopatin" <coolreader.org gmail.com> wrote:


 Sounds cool.

 Can it be used with Vibe.d's system of asynchronous
 connections? If not, then perhaps a backend for mysql-native
 <https://github.com/rejectedsoftware/mysql-native/> could be 
 added?


 
 Actually I'm using mysqln as backend. But I patched it, removing 
 vibe dependancies. (Vibe connection replaced with standard one).


Ahh, ok. In that case, I may diff the two and see about making "vibe.d
connections vs std connections" a configurable choice (with vibe.d
dependency disableable via -version switch). Then perhaps
HibernateD/DDBC users and direct mysql-native users can both benefit
from whichever form they need. Plus that way you wouldn't need to be
bothered with keeping a separate fork of mysqln in sync.
Apr 03 2013
next sibling parent "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Wednesday, 3 April 2013 at 17:22:46 UTC, Nick Sabalausky wrote:

 Actually I'm using mysqln as backend. But I patched it, 
 removing vibe dependancies. (Vibe connection replaced with 
 standard one).


 Ahh, ok. In that case, I may diff the two and see about making 
 "vibe.d
 connections vs std connections" a configurable choice (with 
 vibe.d
 dependency disableable via -version switch). Then perhaps
 HibernateD/DDBC users and direct mysql-native users can both 
 benefit
 from whichever form they need. Plus that way you wouldn't need 
 to be
 bothered with keeping a separate fork of mysqln in sync.


It would be the best solution, to include patch into upstream, 
and use upstream mysqln in DDBC.

Besides connection replacement, I've added some getters to 
retrieve resultset and parameters metadata from mysqln, to 
support NULL blobs, and some more fixes.
Apr 03 2013
prev sibling parent reply "Robert" <jfanatiker gmx.at> writes:
On Wednesday, 3 April 2013 at 17:22:46 UTC, Nick Sabalausky wrote:

 On Wed, 03 Apr 2013 18:54:13 +0200
 "Vadim Lopatin" <coolreader.org gmail.com> wrote:


 Sounds cool.

 Can it be used with Vibe.d's system of asynchronous
 connections? If not, then perhaps a backend for mysql-native
 <https://github.com/rejectedsoftware/mysql-native/> could be 
 added?


 
 Actually I'm using mysqln as backend. But I patched it, 
 removing vibe dependancies. (Vibe connection replaced with 
 standard one).


 Ahh, ok. In that case, I may diff the two and see about making 
 "vibe.d
 connections vs std connections" a configurable choice (with 
 vibe.d
 dependency disableable via -version switch). Then perhaps
 HibernateD/DDBC users and direct mysql-native users can both 
 benefit
 from whichever form they need. Plus that way you wouldn't need 
 to be
 bothered with keeping a separate fork of mysqln in sync.


:-S The better way would be to just depend on a Stream interface
and switch implementations by instantiating different classes. -> 
The used Stream interface would of course need to be factored out 
of vibe, ideally into the standard library.

This would be way more flexible: Users of the library can use 
either implementation without even having to recompile the 
library. No additional runtime cost either.

"-version" should not be used too liberally in my opinion, 
because it is really inflexible, especially when it comes to 
binary/shared libraries.


Best regards,

Robert
Apr 03 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 03 Apr 2013 20:01:54 +0200
"Vadim Lopatin" <coolreader.org gmail.com> wrote:

 
 Besides connection replacement, I've added some getters to 
 retrieve resultset and parameters metadata from mysqln, to 
 support NULL blobs, and some more fixes.


I fixed the NULL blob thing in the main mysql-native's master a few
weeks ago. I'll take a look at the rest.

On Thu, 04 Apr 2013 00:50:39 +0200
"Robert" <jfanatiker gmx.at> wrote:

 :-S The better way would be to just depend on a Stream interface
 and switch implementations by instantiating different classes. -> 
 The used Stream interface would of course need to be factored out 
 of vibe, ideally into the standard library.
 
 This would be way more flexible: Users of the library can use 
 either implementation without even having to recompile the 
 library. No additional runtime cost either.
 


That would indeed be more flexible, but I'm not sure I can imagine a
reason to ever use anything besides phobos connections and vibe.d
connections (but maybe I'm wrong?). Plus, hopefully phobos connections
will eventually gain the ability to work like vibe.d connections and
obviate the need for vibe.d to have it's own connections. So I'm not
sure whether it would really be worth it.


 "-version" should not be used too liberally in my opinion, 
 because it is really inflexible, especially when it comes to 
 binary/shared libraries.
 


I wasn't talking about using -version to switch between
implementations. Just to disable the dependency on vibe.d (which of
course would also disable the *option* of using vibe.d connections).
Apr 05 2013
parent reply "Suliman" <evermind live.ru> writes:
Should ORM be done as separate lib, or it's should become part of 
Phobos?
Apr 06 2013
parent reply David <d dav1d.de> writes:
Am 06.04.2013 14:35, schrieb Suliman:

 Should ORM be done as separate lib, or it's should become part of Phobos?


Why do people want to pack everything into phobos... And better question
why is it then also added to phobos (like curl, wtf)? But that's a
different topic.
Apr 06 2013
parent reply "Suliman" <evermind live.ru> writes:
Because people want standards. For example people want GUI for D, 
but most of the people agree that it would bad idea to create 10 
different GUIs, and it's better have one official GUI.

Look at .NET it's include most of things that developers need at 
real life. And it's one of reasons of it's popularity.
Apr 06 2013
parent reply "BLM768" <blm768 gmail.com> writes:
On Saturday, 6 April 2013 at 12:50:19 UTC, Suliman wrote:

 Because people want standards. For example people want GUI for 
 D, but most of the people agree that it would bad idea to 
 create 10 different GUIs, and it's better have one official GUI.

 Look at .NET it's include most of things that developers need 
 at real life. And it's one of reasons of it's popularity.


At the same time, it's good to have some competition and 
alternative choices. For example, Ruby on Rails is the de facto 
standard for Ruby Web applications, but there are alternatives 
(and pretty decent ones at that). That's why I'm continuing to 
work on my own ORM library, which should still have a niche in 
SQLite-based applications because its API is designed to be 
lightweight and lazy.
Apr 08 2013
parent reply "Suliman" <bubnenkoff gmail.com> writes:
 At the same time, it's good to have some competition and 
 alternative choices.


It's not problem to have 2 realization. Base and alternative. To
have one base realization is always good for thous who need to be
sure that it would not be abandoned.
Apr 08 2013
parent reply David <d dav1d.de> writes:
Am 09.04.2013 08:27, schrieb Suliman:

 At the same time, it's good to have some competition and alternative
 choices.


 
 It's not problem to have 2 realization. Base and alternative. To
 have one base realization is always good for thous who need to be
 sure that it would not be abandoned.


I am looking forward to the date libphobos.a has 1GB in size and takes 5
hours to compile
Apr 10 2013
parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Wednesday, 10 April 2013 at 08:59:07 UTC, David wrote:

 Am 09.04.2013 08:27, schrieb Suliman:

 At the same time, it's good to have some competition and 
 alternative
 choices.


 
 It's not problem to have 2 realization. Base and alternative. 
 To
 have one base realization is always good for thous who need to 
 be
 sure that it would not be abandoned.


 I am looking forward to the date libphobos.a has 1GB in size 
 and takes 5
 hours to compile


std.* may include only interfaces, e.g. like in java.sql package.
Implementations not necessary in std. Can be third party 
libraries (e.g. like java JDBC drivers). But standard interfaces 
give benefits.
Apr 10 2013
parent reply David <d dav1d.de> writes:
Am 10.04.2013 12:26, schrieb Vadim Lopatin:

 On Wednesday, 10 April 2013 at 08:59:07 UTC, David wrote:

 Am 09.04.2013 08:27, schrieb Suliman:

 At the same time, it's good to have some competition and alternative
 choices.


 It's not problem to have 2 realization. Base and alternative. To
 have one base realization is always good for thous who need to be
 sure that it would not be abandoned.


 I am looking forward to the date libphobos.a has 1GB in size and takes 5
 hours to compile


 
 std.* may include only interfaces, e.g. like in java.sql package.
 Implementations not necessary in std. Can be third party libraries (e.g.
 like java JDBC drivers). But standard interfaces give benefits.


So if the std. implementation has a PITA api, all other (probably better
approaches) are forced (forced because the user expects an api like this
and will probably reject something better but with a different api) to
use the same PITA api? This isn't a problem with low-level stuff, but it
is something completly different with something as high-level as an ORM.
Also an api change in the std. implementation forces *every* 3rd party
module to be updated, which is insane, what about a 3 year old
implementation which is basically done, everyone considers it stable,
now the std. implementation makes a small change, thousands of project
will stop working. This isn't a too big problem if the 3 year old
implementation is still activly develeoped, but if it isn't ...
Apr 10 2013
parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Wednesday, 10 April 2013 at 10:35:44 UTC, David wrote:

 Am 10.04.2013 12:26, schrieb Vadim Lopatin:

 On Wednesday, 10 April 2013 at 08:59:07 UTC, David wrote:

 Am 09.04.2013 08:27, schrieb Suliman:

 At the same time, it's good to have some competition and 
 alternative
 choices.


 It's not problem to have 2 realization. Base and 
 alternative. To
 have one base realization is always good for thous who need 
 to be
 sure that it would not be abandoned.


 I am looking forward to the date libphobos.a has 1GB in size 
 and takes 5
 hours to compile


 
 std.* may include only interfaces, e.g. like in java.sql 
 package.
 Implementations not necessary in std. Can be third party 
 libraries (e.g.
 like java JDBC drivers). But standard interfaces give benefits.


 So if the std. implementation has a PITA api, all other 
 (probably better
 approaches) are forced (forced because the user expects an api 
 like this
 and will probably reject something better but with a different 
 api) to
 use the same PITA api? This isn't a problem with low-level 
 stuff, but it
 is something completly different with something as high-level 
 as an ORM.
 Also an api change in the std. implementation forces *every* 
 3rd party
 module to be updated, which is insane, what about a 3 year old
 implementation which is basically done, everyone considers it 
 stable,
 now the std. implementation makes a small change, thousands of 
 project
 will stop working. This isn't a too big problem if the 3 year 
 old
 implementation is still activly develeoped, but if it isn't ...


I cannot find information about PITA. What is it? Is it included 
into Phobos?
Apr 10 2013
parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Wednesday, 10 April 2013 at 11:04:27 UTC, Vadim Lopatin wrote:

 On Wednesday, 10 April 2013 at 10:35:44 UTC, David wrote:

 Am 10.04.2013 12:26, schrieb Vadim Lopatin:

 On Wednesday, 10 April 2013 at 08:59:07 UTC, David wrote:

 Am 09.04.2013 08:27, schrieb Suliman:

 At the same time, it's good to have some competition and 
 alternative
 choices.


 It's not problem to have 2 realization. Base and 
 alternative. To
 have one base realization is always good for thous who need 
 to be
 sure that it would not be abandoned.


 I am looking forward to the date libphobos.a has 1GB in size 
 and takes 5
 hours to compile


 
 std.* may include only interfaces, e.g. like in java.sql 
 package.
 Implementations not necessary in std. Can be third party 
 libraries (e.g.
 like java JDBC drivers). But standard interfaces give 
 benefits.


 So if the std. implementation has a PITA api, all other 
 (probably better
 approaches) are forced (forced because the user expects an api 
 like this
 and will probably reject something better but with a different 
 api) to
 use the same PITA api? This isn't a problem with low-level 
 stuff, but it
 is something completly different with something as high-level 
 as an ORM.
 Also an api change in the std. implementation forces *every* 
 3rd party
 module to be updated, which is insane, what about a 3 year old
 implementation which is basically done, everyone considers it 
 stable,
 now the std. implementation makes a small change, thousands of 
 project
 will stop working. This isn't a too big problem if the 3 year 
 old
 implementation is still activly develeoped, but if it isn't ...


 I cannot find information about PITA. What is it? Is it 
 included into Phobos?


OOPS. Found it in Urban Dictionary :)
Apr 10 2013
parent David <d dav1d.de> writes:
Am 10.04.2013 13:06, schrieb Vadim Lopatin:

 On Wednesday, 10 April 2013 at 11:04:27 UTC, Vadim Lopatin wrote:

 On Wednesday, 10 April 2013 at 10:35:44 UTC, David wrote:

 Am 10.04.2013 12:26, schrieb Vadim Lopatin:

 On Wednesday, 10 April 2013 at 08:59:07 UTC, David wrote:

 Am 09.04.2013 08:27, schrieb Suliman:

 At the same time, it's good to have some competition and alternative
 choices.


 It's not problem to have 2 realization. Base and alternative. To
 have one base realization is always good for thous who need to be
 sure that it would not be abandoned.


 I am looking forward to the date libphobos.a has 1GB in size and
 takes 5
 hours to compile


 std.* may include only interfaces, e.g. like in java.sql package.
 Implementations not necessary in std. Can be third party libraries
 (e.g.
 like java JDBC drivers). But standard interfaces give benefits.


 So if the std. implementation has a PITA api, all other (probably better
 approaches) are forced (forced because the user expects an api like this
 and will probably reject something better but with a different api) to
 use the same PITA api? This isn't a problem with low-level stuff, but it
 is something completly different with something as high-level as an ORM.
 Also an api change in the std. implementation forces *every* 3rd party
 module to be updated, which is insane, what about a 3 year old
 implementation which is basically done, everyone considers it stable,
 now the std. implementation makes a small change, thousands of project
 will stop working. This isn't a too big problem if the 3 year old
 implementation is still activly develeoped, but if it isn't ...


 I cannot find information about PITA. What is it? Is it included into
 Phobos?


 
 OOPS. Found it in Urban Dictionary :)


Hehe :)
Apr 10 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-04-03 16:28, Vadim Lopatin wrote:

 Hello!

 I've started implemetation of ORM in D, with annotations and interfaces
 similar to Hibernate.

 As DB abstraction layer I wrote DDBC - library with interface similar to
 JDBC. Only MySQL driver is implemented. PostgreSQL - in progress.

 Project is hosted on SourceForge:
 https://sourceforge.net/p/hibernated/wiki/HibernateD/ License is Boost

 HibernateD collects metadata from classes annotated with Hibernate-like
 UDAs.

 Simple properties of supported: you can annotate fields, D properties or
 getter+setter pairs in your class, of types string, byte, short, int,
 long, ubyte, ushort, uint, ulong, byte[], ubyte[], DateTime, Date,
 TimeOfDay; for non-nullable types to support Null value use Nullable!
 template.

  Embedded entities supported - you can embed properties from  Embeddable
 object to  Entity's table.

  OneToOne,  OneToMany,  ManyToOne,  ManyToMany relations are supported.
 You can use Lazy! and LazyCollection! to support lazy loading of
 aggregates.

 You can query DB using subset of HQL (Hibernate Query Language).

 Look at project wiki and unittests for more info.


Seems to be fairly complex API. How about using some 
convention-over-configuration.

-- 
/Jacob Carlborg
Apr 03 2013
parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Wednesday, 3 April 2013 at 18:36:16 UTC, Jacob Carlborg wrote:

 On 2013-04-03 16:28, Vadim Lopatin wrote:

 Hello!

 I've started implemetation of ORM in D, with annotations and 
 interfaces
 similar to Hibernate.

 As DB abstraction layer I wrote DDBC - library with interface 
 similar to
 JDBC. Only MySQL driver is implemented. PostgreSQL - in 
 progress.

 Project is hosted on SourceForge:
 https://sourceforge.net/p/hibernated/wiki/HibernateD/ License 
 is Boost

 HibernateD collects metadata from classes annotated with 
 Hibernate-like
 UDAs.

 Simple properties of supported: you can annotate fields, D 
 properties or
 getter+setter pairs in your class, of types string, byte, 
 short, int,
 long, ubyte, ushort, uint, ulong, byte[], ubyte[], DateTime, 
 Date,
 TimeOfDay; for non-nullable types to support Null value use 
 Nullable!
 template.

  Embedded entities supported - you can embed properties from 
  Embeddable
 object to  Entity's table.

  OneToOne,  OneToMany,  ManyToOne,  ManyToMany relations are 
 supported.
 You can use Lazy! and LazyCollection! to support lazy loading 
 of
 aggregates.

 You can query DB using subset of HQL (Hibernate Query 
 Language).

 Look at project wiki and unittests for more info.


 Seems to be fairly complex API. How about using some 
 convention-over-configuration.


I believe HibernateD follows convention-over-configuration 
principles.

As per Wikipedia article for convention-over-configuration, "The 
phrase essentially means a developer only needs to specify 
unconventional aspects of the application. For example, if 
there's a class Sale in the model, the corresponding table in the 
database is called “sales” by default. It is only if one deviates 
from this convention, such as calling the table “products_sold”, 
that one needs to write code regarding these names."

At least, for most annotations in HibernateD, you don't need to 
specify parameters like table or columns names, their types, 
nullability, etc.
By default, they are being generated automatically in reasonable 
way.
Say, for " Entity class CustomerInfo {}" table name 
"customer_info" will be used. For field " Column int 
streetAddress;", column name "street_address" NOT NULL will be 
used. " Column Nullable!long flags;" will be NULL in DB.

Unlike Hibernate, in HibernateD there is on option to treat all 
fields/properties/getters as entity properties automatically, 
even if not annotated. In HibernateD, at least  Column annotation 
should present. Not sure it's a big problem.

Where could convention-over-configuration be used in ORM API 
besides annotations?
Apr 03 2013
parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
I don't see what to simplify in markup like this:

      Entity
     class User {

          Generated
         long id;

          Column
         string name;

          ManyToOne
         Customer customer;

          ManyToMany
         LazyCollection!Role roles;
     }

Which translates to table definitions like
CREATE TABLE user (id bigint not null primary key auto_increment, 
name varchar(255), customer_fk bigint foreign key references 
customer(id));
CREATE TABLE user_roles (user_fk bigint not null foreign key 
references user(id), role_fk int not null foreign key references 
role(id), primary key(user_fk, role_fk);
...
Apr 03 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-04-03 21:07, Vadim Lopatin wrote:

 I don't see what to simplify in markup like this:

       Entity
      class User {

           Generated
          long id;

           Column
          string name;

           ManyToOne
          Customer customer;

           ManyToMany
          LazyCollection!Role roles;
      }

 Which translates to table definitions like
 CREATE TABLE user (id bigint not null primary key auto_increment, name
 varchar(255), customer_fk bigint foreign key references customer(id));
 CREATE TABLE user_roles (user_fk bigint not null foreign key references
 user(id), role_fk int not null foreign key references role(id), primary
 key(user_fk, role_fk);
 ...


Is the attributes necessary at all? I would just go with:

class User
{
     long id; // always assume auto increment, primary key, not null and 
so on
     string name;
     Customer customer; // infer  ManyToOne
      ManyToMany LazyCollection!Role roles; // I guess this cannot be 
inferred
     LazyCollection!Foo foos; // infer  OneToMany
}

Perhaps for primitive types you could have:

class User
{
     Long id;
     String name;
     Int foo;
}

Note the capital letters.

-- 
/Jacob Carlborg
Apr 04 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-04-04 11:01, Jacob Carlborg wrote:


 Perhaps for primitive types you could have:

 class User
 {
      Long id;
      String name;
      Int foo;
 }

 Note the capital letters.


Or:

Id id;

-- 
/Jacob Carlborg
Apr 04 2013
prev sibling parent "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Thursday, 4 April 2013 at 09:01:16 UTC, Jacob Carlborg wrote:

 Is the attributes necessary at all? I would just go with:

 class User
 {
     long id; // always assume auto increment, primary key, not 
 null and so on
     string name;
     Customer customer; // infer  ManyToOne
      ManyToMany LazyCollection!Role roles; // I guess this 
 cannot be inferred
     LazyCollection!Foo foos; // infer  OneToMany
 }

 Perhaps for primitive types you could have:

 class User
 {
     Long id;
     String name;
     Int foo;
 }

 Note the capital letters.


In Hibernate, there are two modes of automatic extraction of 
properties from clas: all fields or all getters/setters. Unless 
field or getter has no  Transient annotation, it's considered as 
property.
I can implement similar behavior.

If class doesn't have class level annotations, we can treat it as 
 Entity.
But in this case it's impossible to find entity classes in 
modules. Currently, HibernateD accept list of classes and/or 
modules, to extract metadata from.
If module is passed, how would we determine if some particular 
class in module is persistent or not? Either we have to import 
ALL classes of module as entities or only annotated.

Having default  ManyToOne for object field and  OneToMany for 
array of objects is a good idea.

It will be nice to define aliases like alias Nullable!long Long;

The question is how to determine what members of class to treat 
as properties?
Currently field, getter/setter pair, and  property supported. 
What should be rule to choose which of them import as fields?
Have a priority of  property access functions and getters/setters 
over usual fields? Ignore private and protected members?

BTW, having getField()/setField() looks like not a D way 
( property should be used instead). Probably, I just can remove 
getters/setters support.
Apr 04 2013
prev sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Wednesday, 3 April 2013 at 19:07:39 UTC, Vadim Lopatin wrote:

 I don't see what to simplify in markup like this:
 ...


You may implement approach similar to one used in vibe.d 
http.rest and http.form modules. Some specific examples are 
described by Jacob, but, in general, in results in 3 
configuration stages:
0) No configuration at all, all data is inferred from variable 
names and types according to some sane convention.
1) Convention configuration - you chose one convention to use for 
aggregate type introspection at compile-time. Few different 
pre-defined conventions exist.
2) Fine configuration using UDAs.
Apr 04 2013
parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Thursday, 4 April 2013 at 09:54:48 UTC, Dicebot wrote:

 On Wednesday, 3 April 2013 at 19:07:39 UTC, Vadim Lopatin wrote:

 I don't see what to simplify in markup like this:
 ...


 You may implement approach similar to one used in vibe.d 
 http.rest and http.form modules. Some specific examples are 
 described by Jacob, but, in general, in results in 3 
 configuration stages:
 0) No configuration at all, all data is inferred from variable 
 names and types according to some sane convention.
 1) Convention configuration - you chose one convention to use 
 for aggregate type introspection at compile-time. Few different 
 pre-defined conventions exist.
 2) Fine configuration using UDAs.



Implemented changes for better convention-over-configuration:
- If no annotations on class level,  Entity is assumed.
- No required annotation for simple properties. Nullability is 
deduced from data type
-  Embedded annotation is not needed anymore - it's deduced from 
field's class  Embeddable annotation
- If no key field annotations specified in class ( Id, 
 Generated,  Generator) - property named "id" (if any) is 
considered to be a  Generated primary key.
- For Object fields  ManyToOne is applied by default
- For Object[] or LazyCollection!Object  OneToMany is applied by 
default
-  OneToOne and  ManyToOne are required, since cannot be deduced

Following declarations are valid (comments describe ):

//  Entity assumed since no  Embeddable annotation
class User {
    long id;         //  Generated deduced from field name
    string name;     // deduced  NotNull
    Address address; // deduced  Embedded from annotation of 
Address
    Customer customer; // deduced  ManyToOne  JoinColumn
    // annotation required, otherwise would be deduced as 
 OneToMany
     ManyToMany Roles[] roles;
}

 Embeddable // required for Embeddable
class Address {
    String zip;           //  Null
    String state;         //  Null
    string streetAddress; //  NotNull
}

//  Entity assumed since no  Embeddable annotation
class Customer {
    int id;     //  Generated primary key - from field name
    string name;//  NotNull
    Long flags; //  Null - because it's Long - not long
    LazyCollection!User users; //  OneToMany by default
    // annotation required, otherwise would be deduced as 
 ManyToOne
    //  JoinColumn is required on one of OneToOne sides
     OneToOne  JoinColumn CustomerOptions customerOptions;
}

//  Entity assumed
class CustomerOptions {
    int id;
    // annotation required, otherwise would be deduced as 
 ManyToOne
     OneToOne Customer customer;
}

//  Entity assumed since no  Embeddable annotation
class Role {
    int id;      //  Generated
    string name; //  NotNull
    // annotation required, otherwise would be deduced as 
 OneToMany
     ManyToMany LazyCollection!User users;
}

Aliases added, to simple put uppercase Long instead of 
Nullable!long in code:
alias Nullable!byte Byte;
alias Nullable!ubyte Ubyte;
alias Nullable!short Short;
alias Nullable!ushort Ushort;
alias Nullable!int Int;
alias Nullable!uint Uint;
alias Nullable!long Long;
alias Nullable!ulong Ulong;
alias Nullable!float Float;
alias Nullable!double Double;
alias Nullable!DateTime NullableDateTime;
alias Nullable!Date NullableDate;
alias Nullable!TimeOfDay NullableTimeOfDay;

String (uppercase nullable version of string) is defined as 
struct wrapper around string field, with interface similar to 
Nullable!
Looks ugly, but I tried `typedef string String`, but it is 
deprecated; `alias string String` cannot be distinguished from 
just string. How to define String better? Is there a good way to 
define String to be compatible with string, but with the ability 
to distinguish between string and String in compile time?
Apr 05 2013
next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Friday, 5 April 2013 at 07:32:55 UTC, Vadim Lopatin wrote:

 Looks ugly, but I tried `typedef string String`, but it is 
 deprecated; `alias string String` cannot be distinguished from 
 just string. How to define String better? Is there a good way 
 to define String to be compatible with string, but with the 
 ability to distinguish between string and String in compile 
 time?


Something like this : http://dpaste.1azy.net/ad013e4ef ?
Apr 05 2013
parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Friday, 5 April 2013 at 07:57:37 UTC, Dicebot wrote:

 On Friday, 5 April 2013 at 07:32:55 UTC, Vadim Lopatin wrote:

 Looks ugly, but I tried `typedef string String`, but it is 
 deprecated; `alias string String` cannot be distinguished from 
 just string. How to define String better? Is there a good way 
 to define String to be compatible with string, but with the 
 ability to distinguish between string and String in compile 
 time?


 Something like this : http://dpaste.1azy.net/ad013e4ef ?


It's as I have already implemented it. 
http://dpaste.1azy.net/a0393ce23
Apr 05 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Friday, 5 April 2013 at 09:26:30 UTC, Vadim Lopatin wrote:

 On Friday, 5 April 2013 at 07:57:37 UTC, Dicebot wrote:

 On Friday, 5 April 2013 at 07:32:55 UTC, Vadim Lopatin wrote:

 Looks ugly, but I tried `typedef string String`, but it is 
 deprecated; `alias string String` cannot be distinguished 
 from just string. How to define String better? Is there a 
 good way to define String to be compatible with string, but 
 with the ability to distinguish between string and String in 
 compile time?


 Something like this : http://dpaste.1azy.net/ad013e4ef ?


 It's as I have already implemented it. 
 http://dpaste.1azy.net/a0393ce23


Why do you redefine constructor (it does exactly the same what 
default one) and prefer getter over raw alias this (thus adding 
necessity for opAssign)? Other than that looks pretty adequate 
match to desired behavior.
Apr 05 2013
parent "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Friday, 5 April 2013 at 09:36:04 UTC, Dicebot wrote:

 On Friday, 5 April 2013 at 09:26:30 UTC, Vadim Lopatin wrote:

 On Friday, 5 April 2013 at 07:57:37 UTC, Dicebot wrote:

 On Friday, 5 April 2013 at 07:32:55 UTC, Vadim Lopatin wrote:

 Looks ugly, but I tried `typedef string String`, but it is 
 deprecated; `alias string String` cannot be distinguished 
 from just string. How to define String better? Is there a 
 good way to define String to be compatible with string, but 
 with the ability to distinguish between string and String in 
 compile time?


 Something like this : http://dpaste.1azy.net/ad013e4ef ?


 It's as I have already implemented it. 
 http://dpaste.1azy.net/a0393ce23


 Why do you redefine constructor (it does exactly the same what 
 default one) and prefer getter over raw alias this (thus adding 
 necessity for opAssign)? Other than that looks pretty adequate 
 match to desired behavior.


Thank you!

It was copy+paste from std.typecons Nullable!
Cleaned it up.
Strange thing: this code doesn't work for me if _value is 
protected - somewhere in CTFE generated code. "_value is 
unaccessible" It's hard to define exact place where it fails 
(inside of mixin).
Tried to write different code which uses String with private 
_value, but cannot reproduce the same error. Leaving public 
_value so far.
Apr 05 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-04-05 09:32, Vadim Lopatin wrote:


 Implemented changes for better convention-over-configuration:
 - If no annotations on class level,  Entity is assumed.
 - No required annotation for simple properties. Nullability is deduced
 from data type
 -  Embedded annotation is not needed anymore - it's deduced from field's
 class  Embeddable annotation
 - If no key field annotations specified in class ( Id,  Generated,
  Generator) - property named "id" (if any) is considered to be a
  Generated primary key.
 - For Object fields  ManyToOne is applied by default
 - For Object[] or LazyCollection!Object  OneToMany is applied by default
 -  OneToOne and  ManyToOne are required, since cannot be deduced

 Following declarations are valid (comments describe ):

 //  Entity assumed since no  Embeddable annotation
 class User {
     long id;         //  Generated deduced from field name
     string name;     // deduced  NotNull
     Address address; // deduced  Embedded from annotation of Address
     Customer customer; // deduced  ManyToOne  JoinColumn
     // annotation required, otherwise would be deduced as  OneToMany
      ManyToMany Roles[] roles;
 }

  Embeddable // required for Embeddable
 class Address {
     String zip;           //  Null
     String state;         //  Null
     string streetAddress; //  NotNull
 }

 //  Entity assumed since no  Embeddable annotation
 class Customer {
     int id;     //  Generated primary key - from field name
     string name;//  NotNull
     Long flags; //  Null - because it's Long - not long
     LazyCollection!User users; //  OneToMany by default
     // annotation required, otherwise would be deduced as  ManyToOne
     //  JoinColumn is required on one of OneToOne sides
      OneToOne  JoinColumn CustomerOptions customerOptions;
 }

 //  Entity assumed
 class CustomerOptions {
     int id;
     // annotation required, otherwise would be deduced as  ManyToOne
      OneToOne Customer customer;
 }

 //  Entity assumed since no  Embeddable annotation
 class Role {
     int id;      //  Generated
     string name; //  NotNull
     // annotation required, otherwise would be deduced as  OneToMany
      ManyToMany LazyCollection!User users;
 }



 String (uppercase nullable version of string) is defined as struct
 wrapper around string field, with interface similar to Nullable!
 Looks ugly, but I tried `typedef string String`, but it is deprecated;
 `alias string String` cannot be distinguished from just string. How to
 define String better? Is there a good way to define String to be
 compatible with string, but with the ability to distinguish between
 string and String in compile time?


Why won't Nullable!(string) String work?

Looks much better know. I'm wondering though, if there need to be a way 
to indicate a regular instance variable that isn't a column.

-- 
/Jacob Carlborg
Apr 05 2013
parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Friday, 5 April 2013 at 08:53:56 UTC, Jacob Carlborg wrote:

 Why won't Nullable!(string) String work?


It's to reduce field size (eliminate unnecessary bool field from 
Nullable!, but it's easy to support both cases.


 Looks much better know. I'm wondering though, if there need to 
 be a way to indicate a regular instance variable that isn't a 
 column.


1) Any private, protected, package members are not columns.
2)  Transient annotation may be applied to public member to say 
that it shouln't be persisted (like in Java)
Apr 05 2013
next sibling parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Friday, 5 April 2013 at 09:22:17 UTC, Vadim Lopatin wrote:

 On Friday, 5 April 2013 at 08:53:56 UTC, Jacob Carlborg wrote:

 Why won't Nullable!(string) String work?


 It's to reduce field size (eliminate unnecessary bool field 
 from Nullable!, but it's easy to support both cases.


 Looks much better know. I'm wondering though, if there need to 
 be a way to indicate a regular instance variable that isn't a 
 column.


 1) Any private, protected, package members are not columns.
 2)  Transient annotation may be applied to public member to say 
 that it shouln't be persisted (like in Java)


Submitted fix to support  Transient.
It can be used on class level as well.

Currently, if module is passed to metadata extractor, only 
classes which have at least one HibernateD annotation are being 
imported.
Alternative is to import all classes, skipping only ones marked 
with  Transient.
Which way is better?
Apr 05 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-04-05 11:44, Vadim Lopatin wrote:


 Submitted fix to support  Transient.
 It can be used on class level as well.

 Currently, if module is passed to metadata extractor, only classes which
 have at least one HibernateD annotation are being imported.
 Alternative is to import all classes, skipping only ones marked with
  Transient.
 Which way is better?


I'm not sure, the current behavior perhaps. I think I would need to try 
it out do have a proper answer.

-- 
/Jacob Carlborg
Apr 05 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-04-05 11:22, Vadim Lopatin wrote:

 On Friday, 5 April 2013 at 08:53:56 UTC, Jacob Carlborg wrote:

 Why won't Nullable!(string) String work?


 It's to reduce field size (eliminate unnecessary bool field from
 Nullable!, but it's easy to support both cases.


Aha, I see. I think you can use Nullable!(string, null). Look at the 
documentation, there's two Nullable:

dlang.org/phobos/std_typecons.html


 Looks much better know. I'm wondering though, if there need to be a
 way to indicate a regular instance variable that isn't a column.


 1) Any private, protected, package members are not columns.


Right, didn't think of that. What about methods, can you have a 
method/property as a column?


 2)  Transient annotation may be applied to public member to say that it
 shouln't be persisted (like in Java)


Sounds good.

-- 
/Jacob Carlborg
Apr 05 2013
parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Friday, 5 April 2013 at 12:13:42 UTC, Jacob Carlborg wrote:

 Looks much better know. I'm wondering though, if there need 
 to be a
 way to indicate a regular instance variable that isn't a 
 column.


 1) Any private, protected, package members are not columns.


 Right, didn't think of that. What about methods, can you have a 
 method/property as a column?


As addition to fields, two more options supported:
1) Getter/setter pair:
      public T getSomeProperty();
      public xxx setSomeProperty(T value);
    or
      public T isSomeProperty();
      public xxx setSomeProperty(T value);
    treated as property with name 'someProperty'

    Second case is useful for boolean, to sound more natural
    Result type of setter doesn't matter.
    Both getter and setter should be defined, otherwise methods 
will be ignored.

2) Read/write property
     property T someProperty() { ... }
     property xxx someProperty(T value) { ... }
    treated as property with name 'someProperty'

BTW, I don't know how to check if property is read/write in 
compile time.
Apr 05 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-04-05 16:03, Vadim Lopatin wrote:


 2) Read/write property
      property T someProperty() { ... }
      property xxx someProperty(T value) { ... }
     treated as property with name 'someProperty'

 BTW, I don't know how to check if property is read/write in compile time.


If there's no better way you can always use __traits(compiles), 
something like this:

__traits(compiles, { auto c = new Class; T v = c.someProperty; 
c.someProperty = T.init; });

Currently that will compile regardless of  property or not.

-- 
/Jacob Carlborg
Apr 05 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Friday, 5 April 2013 at 15:20:06 UTC, Jacob Carlborg wrote:

 On 2013-04-05 16:03, Vadim Lopatin wrote:


 2) Read/write property
     property T someProperty() { ... }
     property xxx someProperty(T value) { ... }
    treated as property with name 'someProperty'

 BTW, I don't know how to check if property is read/write in 
 compile time.


 If there's no better way you can always use __traits(compiles), 
 something like this:

 __traits(compiles, { auto c = new Class; T v = c.someProperty; 
 c.someProperty = T.init; });

 Currently that will compile regardless of  property or not.


Quoting 
https://github.com/rejectedsoftware/vibe.d/blob/master/source/
ibe/http/restutil.d 
:

template isPropertyGetter(T)
{
	enum isPropertyGetter = (functionAttributes!(T) & 
FunctionAttribute.property) != 0
		&& !is(ReturnType!T == void);
}

template isPropertySetter(T)
{
	enum isPropertySetter = (functionAttributes!(T) & 
FunctionAttribute.property) != 0
		&& is(ReturnType!T == void);
}
Apr 05 2013
parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Friday, 5 April 2013 at 15:52:43 UTC, Dicebot wrote:

 On Friday, 5 April 2013 at 15:20:06 UTC, Jacob Carlborg wrote:

 On 2013-04-05 16:03, Vadim Lopatin wrote:


 2) Read/write property
    property T someProperty() { ... }
    property xxx someProperty(T value) { ... }
   treated as property with name 'someProperty'

 BTW, I don't know how to check if property is read/write in 
 compile time.


 If there's no better way you can always use 
 __traits(compiles), something like this:

 __traits(compiles, { auto c = new Class; T v = c.someProperty; 
 c.someProperty = T.init; });

 Currently that will compile regardless of  property or not.


 Quoting 
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/
ibe/http/restutil.d 
 :

 template isPropertyGetter(T)
 {
 	enum isPropertyGetter = (functionAttributes!(T) & 
 FunctionAttribute.property) != 0
 		&& !is(ReturnType!T == void);
 }

 template isPropertySetter(T)
 {
 	enum isPropertySetter = (functionAttributes!(T) & 
 FunctionAttribute.property) != 0
 		&& is(ReturnType!T == void);
 }


I'm iterating through class members using __traits(allMembers, 
T), then accessing member using _traits(getMember,T,memberName)

I'm not sure which one of the members with the same name will be 
returned by getMember... Property getter and setter have the same 
name...

Is there any better way to iterate through members of class?
Apr 05 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Friday, 5 April 2013 at 16:41:53 UTC, Vadim Lopatin wrote:

 I'm iterating through class members using __traits(allMembers, 
 T), then accessing member using _traits(getMember,T,memberName)

 I'm not sure which one of the members with the same name will 
 be returned by getMember... Property getter and setter have the 
 same name...

 Is there any better way to iterate through members of class?


Quoting vibe.d again :)

---
foreach( member; __traits(allMembers, T) ) {
     foreach( overload; MemberFunctionsTuple!(T, method) ) {
---
Apr 05 2013
next sibling parent "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Friday, 5 April 2013 at 17:18:01 UTC, Dicebot wrote:

 On Friday, 5 April 2013 at 16:41:53 UTC, Vadim Lopatin wrote:

 I'm iterating through class members using __traits(allMembers, 
 T), then accessing member using _traits(getMember,T,memberName)

 I'm not sure which one of the members with the same name will 
 be returned by getMember... Property getter and setter have 
 the same name...

 Is there any better way to iterate through members of class?


 Quoting vibe.d again :)

 ---
 foreach( member; __traits(allMembers, T) ) {
     foreach( overload; MemberFunctionsTuple!(T, method) ) {
 ---


Thanks a lot! It looks like Vibe is a good source :)
Apr 05 2013
prev sibling parent "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Friday, 5 April 2013 at 17:18:01 UTC, Dicebot wrote:

 On Friday, 5 April 2013 at 16:41:53 UTC, Vadim Lopatin wrote:

 I'm iterating through class members using __traits(allMembers, 
 T), then accessing member using _traits(getMember,T,memberName)

 I'm not sure which one of the members with the same name will 
 be returned by getMember... Property getter and setter have 
 the same name...

 Is there any better way to iterate through members of class?


 Quoting vibe.d again :)

 ---
 foreach( member; __traits(allMembers, T) ) {
     foreach( overload; MemberFunctionsTuple!(T, method) ) {
 ---


Fixed property support.
Apr 08 2013
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Friday, 5 April 2013 at 07:32:55 UTC, Vadim Lopatin wrote:

  Embeddable // required for Embeddable
 class Address {
    String zip;           //  Null
    String state;         //  Null
    string streetAddress; //  NotNull
 }


Is it good to assume string is not null? For most scenarios 
there's little difference between null and empty string.
Apr 29 2013
parent reply David <d dav1d.de> writes:
Am 29.04.2013 11:25, schrieb Kagamin:

 On Friday, 5 April 2013 at 07:32:55 UTC, Vadim Lopatin wrote:

  Embeddable // required for Embeddable
 class Address {
    String zip;           //  Null
    String state;         //  Null
    string streetAddress; //  NotNull
 }


 
 Is it good to assume string is not null? For most scenarios there's
 little difference between null and empty string.


Null blows up your code, "" doesn't. Also it's a SQL thing, "NotNull"
must be initialized, when the row is filled.
Apr 29 2013
parent reply "Kagamin" <spam here.lot> writes:
On Monday, 29 April 2013 at 09:38:10 UTC, David wrote:

 Null blows up your code, "" doesn't.


There's no difference between null and empty string in D.


 Also it's a SQL thing, "NotNull"
 must be initialized, when the row is filled.


Full SQL support is good to have. I question the decision to make 
it default.
May 06 2013
next sibling parent "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Monday, 6 May 2013 at 09:14:57 UTC, Kagamin wrote:

 On Monday, 29 April 2013 at 09:38:10 UTC, David wrote:

 Null blows up your code, "" doesn't.


 There's no difference between null and empty string in D.


 Also it's a SQL thing, "NotNull"
 must be initialized, when the row is filled.


 Full SQL support is good to have. I question the decision to 
 make it default.


Current implementation looks consistent:

D type -- SQL type
int    -- INT NOT NULL
Int    -- INT NULL
long   -- BIGINT NOT NULL
Long   -- BIGINT NULL
string -- VARCHAR(255) NOT NULL
String -- VARCHAR(255) NULL

Uppercase types are nullable.

 NotNull/ Null annotations are not required. Nullability can be 
inferred from type name.
May 07 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 06 May 2013 11:14:56 +0200
"Kagamin" <spam here.lot> wrote:


 On Monday, 29 April 2013 at 09:38:10 UTC, David wrote:

 Null blows up your code, "" doesn't.


 
 There's no difference between null and empty string in D.
 


That's not true:

    assert("" !is null); // Passes

Or did I misunderstand what you meant?
May 21 2013
parent reply "Diggory" <diggsey googlemail.com> writes:
On Tuesday, 21 May 2013 at 22:24:06 UTC, Nick Sabalausky wrote:

 On Mon, 06 May 2013 11:14:56 +0200
 "Kagamin" <spam here.lot> wrote:


 On Monday, 29 April 2013 at 09:38:10 UTC, David wrote:

 Null blows up your code, "" doesn't.


 
 There's no difference between null and empty string in D.
 


 That's not true:

     assert("" !is null); // Passes

 Or did I misunderstand what you meant?


Strings are slices which are a pointer and a length. I think a 
slice compares equal to null only if the pointer part is null. 
However, a slice with a null pointer and a length of zero is 
still a valid empty slice, which is slightly odd behaviour 
compared to other languages...

An empty string literal initialises the pointer to non-null 
because string literals are null terminated, so the memory block 
actually has a length of one, even though the slice has length 
zero.
May 21 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 22 May 2013 02:10:52 +0200
"Diggory" <diggsey googlemail.com> wrote:


 On Tuesday, 21 May 2013 at 22:24:06 UTC, Nick Sabalausky wrote:

 On Mon, 06 May 2013 11:14:56 +0200
 "Kagamin" <spam here.lot> wrote:


 On Monday, 29 April 2013 at 09:38:10 UTC, David wrote:

 Null blows up your code, "" doesn't.


 
 There's no difference between null and empty string in D.
 


 That's not true:

     assert("" !is null); // Passes

 Or did I misunderstand what you meant?


 
 Strings are slices which are a pointer and a length. I think a 
 slice compares equal to null only if the pointer part is null. 
 However, a slice with a null pointer and a length of zero is 
 still a valid empty slice, which is slightly odd behaviour 
 compared to other languages...
 
 An empty string literal initialises the pointer to non-null 
 because string literals are null terminated, so the memory block 
 actually has a length of one, even though the slice has length 
 zero.


Right, exactly. In other words, there *is* a difference between null and
empty string in D (even though it's sometimes a clouded issue since
'==' counts them as equal).
May 21 2013
next sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 22 May 2013 at 00:19:04 UTC, Nick Sabalausky wrote:

 Right, exactly. In other words, there *is* a difference between 
 null and
 empty string in D (even though it's sometimes a clouded issue 
 since
 '==' counts them as equal).


I meant there's no difference between them in meaningful 
scenarios (where empty string and null behave the same). Your 
example is synthetic (its also unclear wheter you compare strings 
or void*'s). I wouldn't expect this behavior to be reliable as D 
doesn't need distinction between null and empty string.
Jun 25 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 22 May 2013 at 00:19:04 UTC, Nick Sabalausky wrote:

 Right, exactly. In other words, there *is* a difference between 
 null and
 empty string in D (even though it's sometimes a clouded issue 
 since
 '==' counts them as equal).


== compare value, is compare identity. Everything is fine on that 
one.
Jun 25 2013
prev sibling next sibling parent "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Wednesday, 3 April 2013 at 14:28:37 UTC, Vadim Lopatin wrote:

 Hello!

 I've started implemetation of ORM in D, with annotations and 
 interfaces similar to Hibernate.

 As DB abstraction layer I wrote DDBC - library with interface 
 similar to JDBC. Only MySQL driver is implemented. PostgreSQL - 
 in progress.

 Project is hosted on SourceForge: 
 https://sourceforge.net/p/hibernated/wiki/HibernateD/ License 
 is Boost


....

 Look at project wiki and unittests for more info.


Project status update:

Recent changes:
- Better convention-over-configuration support: most of 
annotations are non-mandatory now, inferred from field types
- Automatic creation of DB tables and indexes
Apr 09 2013
prev sibling next sibling parent "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Wednesday, 3 April 2013 at 14:28:37 UTC, Vadim Lopatin wrote:

 Hello!

 I've started implemetation of ORM in D, with annotations and 
 interfaces similar to Hibernate.

 As DB abstraction layer I wrote DDBC - library with interface 
 similar to JDBC. Only MySQL driver is implemented. PostgreSQL - 
 in progress.

 Project is hosted on SourceForge: 
 https://sourceforge.net/p/hibernated/wiki/HibernateD/ License 
 is Boost

 Look at project wiki and unittests for more info.


DDBC/HibernateD Project status update
=====================================

SQLite support added into both DDBC and HibernateD.
Use version identifier(s) USE_MYSQL, USE_SQLITE to enable 
corresponding DBs.
Both SQLite and MySQL pass HibernateD unit tests.

PostgreSQL support implementation is in progress.
Apr 10 2013
prev sibling next sibling parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Wednesday, 3 April 2013 at 14:28:37 UTC, Vadim Lopatin wrote:

 Hello!

 I've started implemetation of ORM in D, with annotations and 
 interfaces similar to Hibernate.

 As DB abstraction layer I wrote DDBC - library with interface 
 similar to JDBC. Only MySQL driver is implemented. PostgreSQL - 
 in progress.

 Project is hosted on SourceForge: 
 https://sourceforge.net/p/hibernated/wiki/HibernateD/ License 
 is Boost


...

 Look at project wiki and unittests for more info.




Project status update:
PostgreSQL support is added to DDBC and HibernateD.

Does anyone have an idea what to do next?
Apr 12 2013
next sibling parent Rory McGuire <rjmcguire gmail.com> writes:
:) nuodb.

On Fri, Apr 12, 2013 at 9:08 AM, Vadim Lopatin <coolreader.org gmail.com>wrote:


 On Wednesday, 3 April 2013 at 14:28:37 UTC, Vadim Lopatin wrote:


 Hello!

 I've started implemetation of ORM in D, with annotations and interfaces
 similar to Hibernate.

 As DB abstraction layer I wrote DDBC - library with interface similar to
 JDBC. Only MySQL driver is implemented. PostgreSQL - in progress.

 Project is hosted on SourceForge: https://sourceforge.net/p/**
 hibernated/wiki/HibernateD/<https://sourceforge.net/p/hibernated/wiki
HibernateD/>License is Boost

  ...


  Look at project wiki and unittests for more info.




 Project status update:
 PostgreSQL support is added to DDBC and HibernateD.

 Does anyone have an idea what to do next?





 Apr 12 2013



prev sibling  parent reply "kdmult" <kdmult ya.ru>  writes:


Hi Vadim,


 Does anyone have an idea what to do next?


It would be great if you publish the DUB package.
Please refer to http://registry.vibed.org/publish.

There is a hint.
Page http://registry.vibed.org/ lists registered DUB packages. To 
see them you have to register and sign in there. Otherwise, you 
will see some product info page.



 Apr 12 2013



 next sibling parent  "kdmult" <kdmult ya.ru>  writes:


 There is a hint.
 Page http://registry.vibed.org/ lists registered DUB packages. 
 To see them you have to register and sign in there. Otherwise, 
 you will see some product info page.


Oops. It looks fixed. :-)



 Apr 12 2013



prev sibling  parent reply "Vadim Lopatin" <coolreader.org gmail.com>  writes:


On Friday, 12 April 2013 at 09:03:56 UTC, kdmult wrote:

 Hi Vadim,


 Does anyone have an idea what to do next?


 It would be great if you publish the DUB package.
 Please refer to http://registry.vibed.org/publish.

 There is a hint.
 Page http://registry.vibed.org/ lists registered DUB packages. 
 To see them you have to register and sign in there. Otherwise, 
 you will see some product info page.


Trying to package DDBC.

https://github.com/buggins/ddbc

dub build fails.
It looks like it tries to build application instead of library, 
although I specified "targetType": "staticLibrary",


Checking dependencies in '/home/lve/src/ddbc'
Building configuration "MySQL", build type debug
Running dmd (compile)...
Linking...
/usr/lib/x86_64-linux-gnu/libphobos2.a(dmain2_47f_1a5.o): In 
function `main':
src/rt/dmain2.d:(.text.main+0xa): undefined reference to `_Dmain'
/usr/lib/x86_64-linux-gnu/libphobos2.a(thread_1a1_1b8.o): In 
function `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6
hread6Thread+0x26): 
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6
hread6Thread+0x31): 
undefined reference to `_tlsstart'
/usr/lib/x86_64-linux-gnu/libphobos2.a(deh2_45f_525.o): In 
function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
....
src/core/thread.d:(.text.thread_entryPoint+0xb0): undefined 
reference to `_tlsstart'
collect2: error: ld returned 1 exit status
--- errorlevel 1
Error: no main function specified
Error: Link command failed with exit code 1


{
     "name": "DDBC",
     "description": "DB Connector for D language, similar to JDBC",
     "authors": ["Vadim Lopatin"],
     "homepage": "http://sourceforge.net/projects/ddbc",
     "license": "Boost Software License (BSL 1.0)",
     "dependencies": {
     },
     "targetType": "staticLibrary",
     "configurations": [
         {
             "name": "MySQL",
             "versions": ["USE_MYSQL"]
         },
         {
             "name": "SQLite",
             "versions": ["USE_SQLITE"],
             "libs-posix": ["sqlite3"],
             "libs-windows": ["sqlite3.lib"]
         },
         {
             "name": "PGSQL",
             "versions": ["USE_PGSQL"],
             "libs-posix": ["pq"],
             "libs-windows": ["libpq.lib"]
         }
     ]
}



 Apr 12 2013



  parent reply "Vadim Lopatin" <coolreader.org gmail.com>  writes:


Still cannot build library using DUB.

Tried different changes in package.json

dub -v
...
[7F6FC283306F:00000000 INF] Running dmd (compile)...
[7F6FC283306F:00000000 dbg] dmd -w -g -debug -c -oftemp.o 
-version=USE_MYSQL -I/home/lve/src/ddbc/source 
source/drivers/sha1.d source/drivers/pgsqlddbc.d 
source/drivers/pgsql.d source/drivers/mysqlddbc.d 
source/drivers/mysql.d source/drivers/utils.d 
source/drivers/sqliteddbc.d source/common.d source/core.d
[7F6FC283306F:00000000 INF] Linking...
[7F6FC283306F:00000000 dbg] dmd -of/tmp/dub/2946988246/libddbc.a 
temp.o
/usr/lib/x86_64-linux-gnu/libphobos2.a(dmain2_47f_1a5.o): In 
function `main':


Why does it try to link app executable instead of just link 
library?


package.json:

{
     "name": "DDBC",
     "description": "DB Connector for D language, similar to JDBC",
     "authors": ["Vadim Lopatin"],
     "homepage": "http://sourceforge.net/projects/ddbc",
     "license": "Boost Software License (BSL 1.0)",
     "sourcePaths": ["source", "source/drivers"],
     "configurations": [
         {
             "name": "MySQL",
             "versions": ["USE_MYSQL"],
             "targetType": "staticLibrary",
             "targetPath": "bin",
             "targetName": "ddbc",
         }
     ]
}



 Apr 12 2013



 next sibling parent reply David <d dav1d.de>  writes:


Am 12.04.2013 15:17, schrieb Vadim Lopatin:

 Still cannot build library using DUB.
 
 Tried different changes in package.json
 
 dub -v
 ...
 [7F6FC283306F:00000000 INF] Running dmd (compile)...
 [7F6FC283306F:00000000 dbg] dmd -w -g -debug -c -oftemp.o
 -version=USE_MYSQL -I/home/lve/src/ddbc/source source/drivers/sha1.d
 source/drivers/pgsqlddbc.d source/drivers/pgsql.d
 source/drivers/mysqlddbc.d source/drivers/mysql.d source/drivers/utils.d
 source/drivers/sqliteddbc.d source/common.d source/core.d
 [7F6FC283306F:00000000 INF] Linking...
 [7F6FC283306F:00000000 dbg] dmd -of/tmp/dub/2946988246/libddbc.a temp.o
 /usr/lib/x86_64-linux-gnu/libphobos2.a(dmain2_47f_1a5.o): In function
 `main':
 
 
 Why does it try to link app executable instead of just link library?
 
 
 package.json:
 
 {
     "name": "DDBC",
     "description": "DB Connector for D language, similar to JDBC",
     "authors": ["Vadim Lopatin"],
     "homepage": "http://sourceforge.net/projects/ddbc",
     "license": "Boost Software License (BSL 1.0)",
     "sourcePaths": ["source", "source/drivers"],
     "configurations": [
         {
             "name": "MySQL",
             "versions": ["USE_MYSQL"],
             "targetType": "staticLibrary",
             "targetPath": "bin",
             "targetName": "ddbc",
         }
     ]
 }


Try to move targetType one level higher?



 Apr 12 2013



  parent reply "Vadim Lopatin" <coolreader.org gmail.com>  writes:


On Friday, 12 April 2013 at 13:22:41 UTC, David wrote:

 [7F6FC283306F:00000000 INF] Linking...
 [7F6FC283306F:00000000 dbg] dmd 
 -of/tmp/dub/2946988246/libddbc.a temp.o





 
 Why does it try to link app executable instead of just link 
 library?





 Try to move targetType one level higher?


Tried. Doesn't help. Changing of targetType to "library" instead 
of "staticLibrary" doesn't help, too.
Link command is always the same:
dmd -of/tmp/dub/2946988246/libddbc.a temp.o



 Apr 12 2013



  parent reply "michaelc37" <michaelc37 msn.com>  writes:


First off; Awesome project (just discovered this).

Is it possible set up the mapping externally in some sort of xml 
configuration file (without using attributes)right now?
If not, is it planned for future?

The reason i ask is because i started playing around with 
nhibernate recently, and really like the fact that i did not have 
to polute(for lack of a better term) the code file with 
attributes.

e.g.
<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                    assembly="Something.Core"
                    namespace="Something.Core.Data.Models">

   <class name="User">
     <id name="Id">
       <generator class="native"></generator>
     </id>
     <property name="FirstName" />
     <property name="LastName" />
   </class>

</hibernate-mapping>



 Apr 13 2013



  parent  "Vadim Lopatin" <coolreader.org gmail.com>  writes:


On Saturday, 13 April 2013 at 16:23:04 UTC, michaelc37 wrote:

 First off; Awesome project (just discovered this).

 Is it possible set up the mapping externally in some sort of 
 xml configuration file (without using attributes)right now?
 If not, is it planned for future?

 The reason i ask is because i started playing around with 
 nhibernate recently, and really like the fact that i did not 
 have to polute(for lack of a better term) the code file with 
 attributes.

 e.g.
 <?xml version="1.0" encoding="utf-8" ?>
 <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                    assembly="Something.Core"
                    namespace="Something.Core.Data.Models">

   <class name="User">
     <id name="Id">
       <generator class="native"></generator>
     </id>
     <property name="FirstName" />
     <property name="LastName" />
   </class>

 </hibernate-mapping>


It's possible to implement this feature, although it would 
require compile-time XML parsing.
But I don't see big benefits from it. It's inconvenient and error 
prone. Properties of the same entity should be edited in two 
separate files, and kept in sync.

Historically, XML annotations were replaced with   annotations in 
JPA/Hibernate once Java got support of  annotations.
Even XML files were usually generated automatically from JavaDoc 
annotations inside comments.



 Apr 15 2013



prev sibling  parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org>  writes:


Sorry, the library target types are still not fully implemented. But  if
the package is used as a dependency instead of being directly built, it
will be properly used as a library instead of as an executable.

I would go with the following minimal package description for now (the
source folder and targetType="library" is inferred automatically):

{
    "name": "DDBC",
    "description": "DB Connector for D language, similar to JDBC",
    "authors": ["Vadim Lopatin"],
    "homepage": "http://sourceforge.net/projects/ddbc",
    "license": "Boost Software License (BSL 1.0)",
    "configurations": [
        {
            "name": "MySQL",
            "versions": ["USE_MYSQL"]
        }
    ]
}

However, there is one issue: The package registry needs to get either
sourceforge.net support, or support to upload arbitrary files (which is
difficult in the long term because of disk space usage). But even
without that support, the package can be used for now using:

$ svn co ... hibernated
$ dub add-local hibernated ~master

with other projects adding it to their package description with:

{
    "dependencies": {"hibernated": "~master"}
}

I'll try to get the missing things sorted out shortly.


Am 12.04.2013 15:17, schrieb Vadim Lopatin:

 Still cannot build library using DUB.
 
 Tried different changes in package.json
 
 dub -v
 ...
 [7F6FC283306F:00000000 INF] Running dmd (compile)...
 [7F6FC283306F:00000000 dbg] dmd -w -g -debug -c -oftemp.o
 -version=USE_MYSQL -I/home/lve/src/ddbc/source source/drivers/sha1.d
 source/drivers/pgsqlddbc.d source/drivers/pgsql.d
 source/drivers/mysqlddbc.d source/drivers/mysql.d source/drivers/utils.d
 source/drivers/sqliteddbc.d source/common.d source/core.d
 [7F6FC283306F:00000000 INF] Linking...
 [7F6FC283306F:00000000 dbg] dmd -of/tmp/dub/2946988246/libddbc.a temp.o
 /usr/lib/x86_64-linux-gnu/libphobos2.a(dmain2_47f_1a5.o): In function
 `main':
 
 
 Why does it try to link app executable instead of just link library?
 
 
 package.json:
 
 {
     "name": "DDBC",
     "description": "DB Connector for D language, similar to JDBC",
     "authors": ["Vadim Lopatin"],
     "homepage": "http://sourceforge.net/projects/ddbc",
     "license": "Boost Software License (BSL 1.0)",
     "sourcePaths": ["source", "source/drivers"],
     "configurations": [
         {
             "name": "MySQL",
             "versions": ["USE_MYSQL"],
             "targetType": "staticLibrary",
             "targetPath": "bin",
             "targetName": "ddbc",
         }
     ]
 }





 Apr 16 2013



  parent reply "Vadim Lopatin" <coolreader.org gmail.com>  writes:


On Tuesday, 16 April 2013 at 07:41:04 UTC, Sönke Ludwig wrote:

 Sorry, the library target types are still not fully 
 implemented. But  if
 the package is used as a dependency instead of being directly 
 built, it
 will be properly used as a library instead of as an executable.


Hello,

I've sent pull request with fix.
At least this fix resolves ddbc build issue.

P.S: I've registered ddbc and hibernated in DUB repository.



 Apr 17 2013



  parent reply "kdmult" <kdmult ya.ru>  writes:


 P.S: I've registered ddbc and hibernated in DUB repository.


I have tried to generate a visuald project which depends on both.
There is a couple of issues.
1. Since you use prefix hibernated (for example, hibernated.core) 
there should be subfolder hibernated under source. And the source 
code should go there.
2. In dependencies I was forced to use version "~master" instead 
of a certain version.

Is there a simple example of using hibernated with sqlite driver?



 Apr 17 2013



  parent  "Vadim Lopatin" <coolreader.org gmail.com>  writes:


On Wednesday, 17 April 2013 at 13:46:30 UTC, kdmult wrote:

 P.S: I've registered ddbc and hibernated in DUB repository.


 I have tried to generate a visuald project which depends on 
 both.
 There is a couple of issues.
 1. Since you use prefix hibernated (for example, 
 hibernated.core) there should be subfolder hibernated under 
 source. And the source code should go there.
 2. In dependencies I was forced to use version "~master" 
 instead of a certain version.

 Is there a simple example of using hibernated with sqlite 
 driver?


I've fixed directory structure.

You need to use SQLite config for both DDBC and HibernateD 
(USE_SQLITE version code defined).
Look at unittests for sample usage (hibernated.tests module).

You need sqlite .lib and .dll to build under windows.



 Apr 18 2013



prev sibling  parent  "Vadim Lopatin" <coolreader.org gmail.com>  writes:


New version: v0.2.9
Fixed HQL parser bug with underscores in field and table names
Fixed compilation error with undefined identifiers in metadata.d
Merged pull request to use standard mysql-native library



 Jun 19 2013