View mode: basic / threaded / horizontal-split · Log in · Help
February 14, 2007
Application is out of sync. with the DB
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
February 15, 2007
Re: RoR, Judge Judy, and little old ladies
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
February 15, 2007
Re: RoR, Judge Judy, and little old ladies
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
February 16, 2007
Re: RoR, Judge Judy, and little old ladies
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
February 16, 2007
Re: RoR, Judge Judy, and little old ladies
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
February 18, 2007
Re: RoR, Judge Judy, and little old ladies
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
February 18, 2007
Re: RoR, Judge Judy, and little old ladies
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
February 20, 2007
Re: RoR, Judge Judy, and little old ladies
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.
February 21, 2007
Re: RoR, Judge Judy, and little old ladies
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
February 22, 2007
Re: RoR, Judge Judy, and little old ladies
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.
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home