|
- 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 |
|
7 | 7 | |
---|
8 | 8 | '''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 |
---|
13 | 13 | |
---|
14 | 14 | '''Case studies we need to consider when developing DeActive''' |
---|
15 | 15 | |
---|
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? |
---|
21 | 21 | |
---|
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.'' |
---|
| 22 | Using 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]] |
---|
24 | 25 | |
---|
25 | 26 | Every 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. |
---|
29 | 30 | === Generated Code isn't a bad thing === |
---|
30 | 31 | |
---|
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. |
---|
| 32 | Generated 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. |
---|
32 | 33 | |
---|
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) |
---|
| 34 | We 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. |
---|
| 37 | 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) |
---|
34 | 38 | |
---|
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. |
---|
38 | 41 | |
---|
39 | 42 | Each 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. |
---|
50 | 53 | Possible to define imports for associated tables (in a similar manner to all) |
---|
51 | 54 | |
---|
52 | | '''Types''' |
---|
| 55 | === Types === |
---|
53 | 56 | It'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. |
---|
54 | 57 | A 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 | }}} |
---|
| 62 | Other types could be handed in a similar manner. |
---|
56 | 63 | |
---|
57 | | |
---|
58 | | |
---|
59 | | |
---|
60 | 64 | === The Factory class === |
---|
61 | 65 | Each 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. |
---|
62 | 66 | {{{ |
---|
| 67 | #!d |
---|
63 | 68 | class TableNameFactory // better naming scheme? |
---|
64 | 69 | { |
---|
76 | 81 | You can override implementations without a deep class hierarchy. |
---|
77 | 82 | {{{ |
---|
| 83 | #!d |
---|
78 | 84 | template Model(S) |
---|
79 | 85 | { |
---|
107 | 113 | } |
---|
108 | 114 | }}} |
---|
109 | | ! unimplemented, untested, written on the fly code! |
---|
| 115 | '''Note: unimplemented, untested, written on the fly code! ''' |
---|
110 | 116 | |
---|
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 === |
---|
| 118 | Associations can be preformed with structs as well, generated code would be able to generate the associations on the fly |
---|
113 | 119 | {{{ |
---|
| 120 | #!d |
---|
114 | 121 | // one to one |
---|
115 | 122 | struct Person |
---|
140 | 147 | |
---|
141 | 148 | === Anne's user case === |
---|
142 | | When using conventions, or associations we need to keep in mind preexisting database setups. A proposal on that aspect. |
---|
| 149 | When using conventions, or associations we need to keep in mind pre-existing database setups. Here's a proposal on that aspect. |
---|
143 | 150 | |
---|
144 | 151 | When reading the database and generating code we can generate a dsl of sorts in pure D. Not some parsed syntax, but pure D. |
---|
145 | 152 | {{{ |
---|
| 153 | #!d |
---|
146 | 154 | Model ( |
---|
147 | 155 | Database ( |
|
|
|
|
|
Copyright © 2006-2024 Tango. All Rights Reserved. | Page Width:
Static or
Dynamic