The DeRailed Challenge

[Robby]

comments inline :)

BLS wrote:
> kris schrieb:
> 
>> 4) A back-end interface, to the DB. DDBI currently looks like a 
>> reasonable solution, and there's  work currently under way to make it 
>> much more useful.
> 
> Hi Kris,
> DB Frontend and Backend design is my bread and butter job, so I guess I 
> am qualified enough to say that connecting to, and querying a DB is not 
> enough.  Data Encapsulation and Data Binding is needed in order to 
> create Frontend (WEB/Desktop) applications.
> 
> The Java folks allready have a solution, which depends NOT (nessesarily) 
>  on JDBC. IMO this set of classes can be easily established in D. (since 
> Tango)
> I would like to encourage you and the DDBI team to have a look at:
> 
> http://swinglabs.org/docs/frameworks/databuffer/index.jsp
> HTH, Bjoern
> 
Ugh, Please no ;)

IMO an ORM wrapper shouldn't ever care about creating a database. If you 
need the functionality I would say it could be a secondary concern in a 
secondary package.

There are several tools out there to create your tables, columns, etc. 
Most of which are very tailored (read, performance inclined) which would 
take a lot of machinery (and thus man hours) in perfecting. Then you're 
looking at the implementation, which will be cumbersome.


Secondly, I think the following
// abstracted away
struct Person
{
	char[] name;
	Address address;
}
struct Address
{
	char[] street;
	char[] city;
}

// written code
Person p;
Address a;
with (a)
{
	street = "1600 Penn Ave.";
	city = "Wash DC";
}
with(p)
{
	name = "BrightOne";
	address a;
}
People.save(p);
Person[] peeps = People.find(1,2,3);
Person[] peeps2 = People.find("name = 'bright one'");
Looks a lot cleaner, could be cleaned up a bit though.
> A personal note
> Having a visual 2 way database design and maintenance tool using DDBI 
> creating data encapsulation and binding code based on f.i. a databuffer 
> api will make the DSL discussion obsolete.

Unless you want to define in code every little detail, there will need 
to be some version of a DSL to allow legacy applications to absorb 
conventions used by an abstraction implementation. A DSL could be in 
pure D code though, and -run, it doesn't have to be a totally different 
language all together.
> next (the redux discussion)
> Andrei is a Nerd, in no case he is a pragmatic programmer; Of course a 
> financial Institute like M. Chase will not modify the DB design 2 times 
> a week, but 1) there are more dynamic markets and 2) during the 
> development life cycle, means  from version 0 to 1 this happens quit 
> often and it is a pain to writing hard-wired db code.
> 
ugh
> Bjoern