Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Changes between Version 1 and Version 2 of DeActive

Show
Ignore:
Author:
brad (IP: 68.219.44.120)
Timestamp:
02/10/07 15:57:22 (17 years ago)
Comment:

cleaned up markup as I read it

Legend:

Unmodified
Added
Removed
Modified
  • DeActive

    v1 v2  
    77 
    88'''Concepts gotten right by the mainstream implementations:''' 
    9        * conventions are not a bad thing 
    10        * over configuration is 
    11        * conventions with smart defaults are great 
    12        * adaptable conventions aren't magic, they're necessary 
     9 * conventions are not a bad thing 
     10 * over configuration is 
     11 * conventions with smart defaults are great 
     12 * adaptable conventions aren't magic, they're necessary 
    1313         
    1414'''Case studies we need to consider when developing DeActive''' 
    1515 
    16   * Bob is starting a new application and needs DeActive to control his model logic. 
    17   * Anne has an existing application she's wanting to move over to D, thus her schema is already defined. 
    18   * Charlie has already had an implementation in DeActive, but needs to change his database schema. 
    19   * Greg has an GUI application that needs a database based backend. 
    20   * More? 
     16 * Bob is starting a new application and needs DeActive to control his model logic. 
     17 * Anne has an existing application she's wanting to move over to D, thus her schema is already defined. 
     18 * Charlie has already had an implementation in DeActive, but needs to change his database schema. 
     19 * Greg has an GUI application that needs a database based backend. 
     20 * More? 
    2121 
    22 Using the database to get the needed information, and with conventions modeling against it 
    23  ''- in this context we need to ignore Anne's usercase for a minute, I'll come back to it later.'' 
     22Using the database to get the needed information, and with conventions modeling against it[[br]] 
     23 
     24''In this context we need to ignore Anne's usercase for a minute, I'll come back to it later.''[[br]][[br]] 
    2425  
    2526Every database implementation that I know of, and possibly some I don't allows you to get the information about the database and tables it consists of. It also allows you to get the columns, the types, basically.. the entire information you would need to develop a dedicated ORM. 
    2930=== Generated Code isn't a bad thing === 
    3031 
    31 Generate code can help along the way as long as it can handle changes to the code that was generated. This is possible in D, with a few considerations. 
     32Generated code can help along the way as long as it can handle changes to the code that was generated. This is possible in D, with a few considerations. 
    3233 
    33 We generate a struct based on the table layout. Determining the types on the columns and the names during the generation cycle.~1 There should be conventions applied to column naming to allow specialized types to occur.~2 Having each row linked to a struct should allow us to keep performance optimal, while allowing representation to occur at a readable level. The conventions should provide smart defaults, with an option to override for Anne's usercase mentioned above (the database is already defined, so changing it to suit DeActive would be a silly, and costly cause) 
     34We generate a struct based on the table layout, determining the types on the columns and the names during the generation cycle. 
     35 1. There should be conventions applied to column naming to allow specialized types to occur. 
     36 2. Having each row linked to a struct should allow us to keep performance optimal, while allowing representation to occur at a readable level.  
     37The conventions should provide smart defaults, with an option to override for Anne's usercase mentioned above (the database is already defined, so changing it to suit DeActive would be a silly, and costly cause) 
    3438 
    35 ~1 There is a need to convert names in a way that is legal in D, so spaces would have to be converted to underlines. 
    36  
    37 ~2 An example would be a datetime column named created_on. This column would have a datetime inserted on the insert of the object.  
     39 1. There is a need to convert names in a way that is legal in D, so spaces would have to be converted to underlines. 
     40 2. An example would be a datetime column named created_on. This column would have a datetime inserted on the insert of the object.  
    3841 
    3942Each generation cycle would only change the structs that map to the tables, as *they should*. If there is a change into the database schema it needs to be represented into code. There shouldn't be any reason to implement anything inside the structs, they are strictly a throw away type. 
    5053Possible to define imports for associated tables (in a similar manner to all) 
    5154 
    52 '''Types''' 
     55=== Types === 
    5356It's worth noting that you can, within limits have one to one types with most of d's built in types. But it wouldn't be optimal. 
    5457A char[] could technically map to a varchar field, but in doing so wouldn't have the length limitation, or the default limitation defined. we could use a struct in place called varchar that could handle the workload. 
    55         varchar(length,"default"); Other types could be handed in a similar manner. 
     58{{{ 
     59#!d 
     60    varchar(length,"default"); 
     61}}} 
     62Other types could be handed in a similar manner. 
    5663         
    57  
    58  
    59  
    6064=== The Factory class === 
    6165Each table gets a factory class generated. This is where the custom code is implemented. The factory class handles all interaction to the database. Most of the code can be implemented into a mixin. 
    6266{{{ 
     67#!d 
    6368class TableNameFactory // better naming scheme? 
    6469{ 
    7681You can override implementations without a deep class hierarchy. 
    7782{{{ 
     83#!d 
    7884template Model(S) 
    7985{ 
    107113} 
    108114}}} 
    109 ! unimplemented, untested, written on the fly code! 
     115'''Note: unimplemented, untested, written on the fly code! ''' 
    110116 
    111 Associations 
    112        Associations can be preformed with structs as well, generated code would be able to generate the associations on the fly 
     117=== Associations === 
     118Associations can be preformed with structs as well, generated code would be able to generate the associations on the fly 
    113119{{{      
     120#!d 
    114121// one to one 
    115122struct Person 
    140147 
    141148=== Anne's user case === 
    142 When using conventions, or associations we need to keep in mind preexisting database setups. A proposal on that aspect. 
     149When using conventions, or associations we need to keep in mind pre-existing database setups. Here's a proposal on that aspect. 
    143150 
    144151When reading the database and generating code we can generate a dsl of sorts in pure D. Not some parsed syntax, but pure D. 
    145152{{{ 
     153#!d 
    146154Model ( 
    147155        Database (