Hi Andrei, as promised some ideas to solve the Application is out of sync. with the DB

Simplified, ORM around a customer table.
Our code :

class CUSTOMER
{
	// map the table structure
	ulong id;
	char[] lastname;
	char[] firstname.

	// do something
	void write()
	void del()
	void query()
	
}

Problem -> Tablestructure is out of sync. Added Middle Initial to table structure.

Instead of mapping the table into concrete data types, I would kike to suggest to use
memory-mapped files instead;
Due to the fact that you are allways able to query the database system tables you should be able to
extract all nessesary information. to query, update... the db

Another solution requires that a D compiler and DDL are part ouf your application.
Uses
if applicationOutOfSync()
   generateAdequateCode(), compile2DDL()
LoadCodeAtRuntime()
This will at least solve the compile-time problem <g>

Bjoern



Andrei Alexandrescu (See Website For Email) schrieb:
> BLS wrote:
> 
>> Hi Andrei,
>>
>> Andrei Alexandrescu (See Website For Email) schrieb:
>>
>>> Sorry, I'm not sure I understand. My understanding of the mechanism is the following:
>>>
>>> 1. The app runs a SQL-to-target-language parser to build an idea about the database.
>>>
>>> 2. The database folk changes the database in any number of ways. This is not a process that automatically notifies the target language application.
>>>
>>> 3. The target language application must undergo some change to accommodate the change in the database.
>>>
>>> I did DB/financial work in 1998. This scenario was a total bitch because we didn't have small and fast test cases for all logic code to run when the database changed. Basically it was the customer (financial analysts) who let us know when something bombed, and they actually got so used to it that they even weren't pissed anymore.
>>> Andrei
>>
>>
>> I understand and I know about the problem. Due to the fact that this is a serious task, which should not be answered (like before) within a simple statement, and the fact that I am not used to think and argue in english, requires that I have to write down my thoughts in german first and to translate them later. This may take a while, I hope you understand.
>>
>> Allow me a few WHYs
>> WHY a datastore called database has such an influence/impact  on consumer applications, f.i. your Software ? I mean a database should be
>> a Black Box ONLY accessable through your application by using a public key in the sense of (PGP)... Your Application should master the database and not vice versa.
>>
>> Since about 24 years I am in the database business and I have seen only one implemantation which keeps you away from this kind of trouble, let me quote /
>> Suneido has an integrated client-server relational database. The database is accessed via a language which includes administration requests and update operations as well as actual queries. The query language is based on the relational algebra language in An Introduction to Database Systems by C.J.Date.
>> /
>>
>> D is young and refreshing: So WHY not implementing this kind of DB System in D ?
>>
>> Since I know that you are very busy I hesitate to offer you a this link  but I think you will find some very interesting information worth spending a few minutes...
>> http://www.suneido.com/index.php?option=com_content&task=view&id=49&Itemid=1 
>>
>>
>> Further. a big step
>> I could imagine that it could be a matter of interest to port the new MINIX  kernel into D having a DB system instead of "journaling file system"  (Beside, still wonder why this kind of filesys. is not allready reality) Why not doing  that in D ? This is indeed a  vision and as our old german chanceler "Helmut Schmidt" says : People having visions should see a doctor really quick.
> 
> 
> I've seen Tanenbaum talking about Minix. It's a jewel; the kernel is only 4000 lines of code, and everything else is modularly implementable in user space. Writing Minix's kernel in D would definitely be an interesting D project.
> 
> 
> Andrei

Robby wrote:
> Bruno Medeiros wrote:
>> In both cases, Ruby code is generated from
>> code in these two DSLs, but that code generation is performed not by the Ruby compiler during compile-time, but by an external tool (similar to parser generators for example).
> No, it's done with Ruby during run time, using Ruby's dynamic and reflective abilities.
> 

Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Robby wrote:
>> Bruno Medeiros wrote:
>>> In both cases, Ruby code is generated from
>>> code in these two DSLs, but that code generation is performed not by the Ruby compiler during compile-time, but by an external tool (similar to parser generators for example).
>> No, it's done with Ruby during run time, using Ruby's dynamic and reflective abilities.
> 
> Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?

Unless you actually want to do something with that data, I assume.


Sean

Sean Kelly wrote:
> Bruno Medeiros wrote:
>> Robby wrote:
>>> Bruno Medeiros wrote:
>>>> In both cases, Ruby code is generated from
>>>> code in these two DSLs, but that code generation is performed not by the Ruby compiler during compile-time, but by an external tool (similar to parser generators for example).
>>> No, it's done with Ruby during run time, using Ruby's dynamic and reflective abilities.
>>
>> Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?
> 
> Unless you actually want to do something with that data, I assume.
> 
> 
> Sean

What do you mean? I am of course talking in the case where the web app works with the data, otherwise the point of needing or not needing to restart the app was moot.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Sean Kelly wrote:
>> Bruno Medeiros wrote:
>>> Robby wrote:
>>>> Bruno Medeiros wrote:
>>>>> In both cases, Ruby code is generated from
>>>>> code in these two DSLs, but that code generation is performed not by the Ruby compiler during compile-time, but by an external tool (similar to parser generators for example).
>>>> No, it's done with Ruby during run time, using Ruby's dynamic and reflective abilities.
>>>
>>> Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?
>>
>> Unless you actually want to do something with that data, I assume.
> 
> What do you mean? I am of course talking in the case where the web app works with the data, otherwise the point of needing or not needing to restart the app was moot.

So say you modify your schema and the application self-adapts.  Unless it is designed to merely pass all data through to the user (which may be common in web apps), the app will require some specialized code to operate on the data to achieve the desired result.  This obviously cannot be generated automatically because only the programmer knows what it should be.


Sean

Sean Kelly wrote:
> Bruno Medeiros wrote:
>> Sean Kelly wrote:
>>> Bruno Medeiros wrote:
>>>> Robby wrote:
>>>>> Bruno Medeiros wrote:
>>>>>> In both cases, Ruby code is generated from
>>>>>> code in these two DSLs, but that code generation is performed not by the Ruby compiler during compile-time, but by an external tool (similar to parser generators for example).
>>>>> No, it's done with Ruby during run time, using Ruby's dynamic and reflective abilities.
>>>>
>>>> Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?
>>>
>>> Unless you actually want to do something with that data, I assume.
>>
>> What do you mean? I am of course talking in the case where the web app works with the data, otherwise the point of needing or not needing to restart the app was moot.
> 
> So say you modify your schema and the application self-adapts.  Unless it is designed to merely pass all data through to the user (which may be common in web apps), the app will require some specialized code to operate on the data to achieve the desired result.  This obviously cannot be generated automatically because only the programmer knows what it should be.
> 
> 
> Sean

I suspect we're not understanding each other well. Of course business logic is something that only the programmer knows, and the app cannot generate that, but I'm not talking about actual business logic,  just simple domain object creating, deletion, editing (and respective ORM logic). Consider this pic from the article:
http://www.onlamp.com/onlamp/2006/12/14/graphics/figure011.gif
where the web app allows to create a domain object (recipe). That functionality is automatically generated from the SQL tables, it is achieved without any code written (except for SQL table creation).
My question was whether this functionality was generated at "pre-run" time (the scaffolding external tool), or at runtime (by the Ruby webapp and it's dynamic capabilities).


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Sean Kelly wrote:
>> Bruno Medeiros wrote:
>>> Sean Kelly wrote:
>>>> Bruno Medeiros wrote:
>>>>> Robby wrote:
>>>>>> Bruno Medeiros wrote:
>>>>>>> In both cases, Ruby code is generated from
>>>>>>> code in these two DSLs, but that code generation is performed not by the Ruby compiler during compile-time, but by an external tool (similar to parser generators for example).
>>>>>> No, it's done with Ruby during run time, using Ruby's dynamic and reflective abilities.
>>>>>
>>>>> Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?
>>>>
>>>> Unless you actually want to do something with that data, I assume.
>>>
>>> What do you mean? I am of course talking in the case where the web app works with the data, otherwise the point of needing or not needing to restart the app was moot.
>>
>> So say you modify your schema and the application self-adapts.  Unless it is designed to merely pass all data through to the user (which may be common in web apps), the app will require some specialized code to operate on the data to achieve the desired result.  This obviously cannot be generated automatically because only the programmer knows what it should be.
>>
>>
>> Sean
> 
> I suspect we're not understanding each other well. Of course business logic is something that only the programmer knows, and the app cannot generate that, but I'm not talking about actual business logic,  just simple domain object creating, deletion, editing (and respective ORM logic). Consider this pic from the article:
> http://www.onlamp.com/onlamp/2006/12/14/graphics/figure011.gif
> where the web app allows to create a domain object (recipe). That functionality is automatically generated from the SQL tables, it is achieved without any code written (except for SQL table creation).
> My question was whether this functionality was generated at "pre-run" time (the scaffolding external tool), or at runtime (by the Ruby webapp and it's dynamic capabilities).

Yah, I have the same question. My current understanding is that generation is done statically (e.g. you must run the xyz program after you update your database structure...), which makes D's capability of doing that during compilation very attractive.

Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Bruno Medeiros wrote:
>> Sean Kelly wrote:
>>> Bruno Medeiros wrote:
>>>> Sean Kelly wrote:
>>>>> Bruno Medeiros wrote:
>>>>>> Robby wrote:
>>>>>>> Bruno Medeiros wrote:
>>>>>>>> In both cases, Ruby code is generated from
>>>>>>>> code in these two DSLs, but that code generation is performed not by the Ruby compiler during compile-time, but by an external tool (similar to parser generators for example).
>>>>>>> No, it's done with Ruby during run time, using Ruby's dynamic and reflective abilities.
>>>>>>
>>>>>> Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?
>>>>>
>>>>> Unless you actually want to do something with that data, I assume.
>>>>
>>>> What do you mean? I am of course talking in the case where the web app works with the data, otherwise the point of needing or not needing to restart the app was moot.
>>>
>>> So say you modify your schema and the application self-adapts.  Unless it is designed to merely pass all data through to the user (which may be common in web apps), the app will require some specialized code to operate on the data to achieve the desired result.  This obviously cannot be generated automatically because only the programmer knows what it should be.
>>>
>>>
>>> Sean
>>
>> I suspect we're not understanding each other well. Of course business logic is something that only the programmer knows, and the app cannot generate that, but I'm not talking about actual business logic,  just simple domain object creating, deletion, editing (and respective ORM logic). Consider this pic from the article:
>> http://www.onlamp.com/onlamp/2006/12/14/graphics/figure011.gif
>> where the web app allows to create a domain object (recipe). That functionality is automatically generated from the SQL tables, it is achieved without any code written (except for SQL table creation).
>> My question was whether this functionality was generated at "pre-run" time (the scaffolding external tool), or at runtime (by the Ruby webapp and it's dynamic capabilities).
> 
> Yah, I have the same question. My current understanding is that generation is done statically (e.g. you must run the xyz program after you update your database structure...), which makes D's capability of doing that during compilation very attractive.
> 
> Andrei

I don't think it is static, based on this quote:

When Active Record first uses a particular model, it goes to the database and determines the column set of the corresponding table. From there it constructs a set of Column objects. These objects are accessible using the columns( ) class method, and the Column object for a named column can be retrieved using the columns_hash( ) method. The Column objects encode the database column’s name, type, and default value.
 -- Agile Development with Rails, section 15.6.

Don Clugston wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Bruno Medeiros wrote:
>>> Sean Kelly wrote:
>>>> Bruno Medeiros wrote:
>>>>> Sean Kelly wrote:
>>>>>> Bruno Medeiros wrote:
>>>>>>> Robby wrote:
>>>>>>>> Bruno Medeiros wrote:
>>>>>>>>> In both cases, Ruby code is generated from
>>>>>>>>> code in these two DSLs, but that code generation is performed not by the Ruby compiler during compile-time, but by an external tool (similar to parser generators for example).
>>>>>>>> No, it's done with Ruby during run time, using Ruby's dynamic and reflective abilities.
>>>>>>>
>>>>>>> Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?
>>>>>>
>>>>>> Unless you actually want to do something with that data, I assume.
>>>>>
>>>>> What do you mean? I am of course talking in the case where the web app works with the data, otherwise the point of needing or not needing to restart the app was moot.
>>>>
>>>> So say you modify your schema and the application self-adapts.  Unless it is designed to merely pass all data through to the user (which may be common in web apps), the app will require some specialized code to operate on the data to achieve the desired result.  This obviously cannot be generated automatically because only the programmer knows what it should be.
>>>>
>>>>
>>>> Sean
>>>
>>> I suspect we're not understanding each other well. Of course business logic is something that only the programmer knows, and the app cannot generate that, but I'm not talking about actual business logic,  just simple domain object creating, deletion, editing (and respective ORM logic). Consider this pic from the article:
>>> http://www.onlamp.com/onlamp/2006/12/14/graphics/figure011.gif
>>> where the web app allows to create a domain object (recipe). That functionality is automatically generated from the SQL tables, it is achieved without any code written (except for SQL table creation).
>>> My question was whether this functionality was generated at "pre-run" time (the scaffolding external tool), or at runtime (by the Ruby webapp and it's dynamic capabilities).
>>
>> Yah, I have the same question. My current understanding is that generation is done statically (e.g. you must run the xyz program after you update your database structure...), which makes D's capability of doing that during compilation very attractive.
>>
>> Andrei
> 
> I don't think it is static, based on this quote:
> 
> When Active Record first uses a particular model, it goes to the database and determines the column set of the corresponding table. From there it constructs a set of Column objects. These objects are accessible using the columns( ) class method, and the Column object for a named column can be retrieved using the columns_hash( ) method. The Column objects encode the database column’s name, type, and default value.
>  -- Agile Development with Rails, section 15.6.
> 

I asked a friend of mine who knows more about Ruby than me, and he said that Rails can actually do that generation in both occasions (runtime and "pre-run" time). If that's the case it surely would explain the confusion. :)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros schrieb:
> 
> I asked a friend of mine who knows more about Ruby than me, and he said that Rails can actually do that generation in both occasions (runtime and "pre-run" time). If that's the case it surely would explain the confusion. :)
> 

I can confirm this! You have the possibilities to do it this or that way. Personally I use it this way:
First, I use dynamically generated scaffolding to look, that everything is right with my models, and then, if my models are okay, then i use a builtin script to generate written files for it. After that i iterate over the files over and over again, till i'm finished with it.