Ticket #18 (enhancement)
Opened 8 years ago
Last modified 7 years ago
Use existing DB structure to inform model design
Status: closed (fixed)
| Reported by: | docwhat | Assigned to: | fumanchu |
|---|---|---|---|
| Priority: | major | Milestone: | 1.5 |
| Component: | Storage | Keywords: | |
| Cc: | Estimate (total hours): | 32 | |
We like having the DB foreign keys and other constraints, so when some poor human (usually us) goes to make a change the DB retains integrity in spite of us. I noticed that Foreign keys and such aren't used. Is this not possible, or can it be added into the StorageManager? somehow?
Change History
10/05/05 21:14:21: Modified by fumanchu
- status changed from new to assigned.
11/26/05 08:25:56: Modified by fumanchu
02/17/06 00:08:49: Modified by fumanchu
- summary changed from Constraint-awareness to Use existing DB structure to inform model design.
If this is to be implemented, it will be on the level of a tool to auto-generate a Dejavu model (set of Unit classes) from a given DB. A possible second step would be a way to then compare a given Dejavu model to such an auto-generated model (for example, to see what needs to change in your model if your DB schema changes). None of this checking should happen at runtime of the core library--the model layer should implement "the same functionality" so that 1) its presence can be guaranteed for all storage types (not just DB's), and 2) to provide a uniform API regardless of store.
03/09/06 20:58:12: Modified by fumanchu
- priority changed from minor to major.
- milestone set to 1.5.
07/21/06 16:54:04: Modified by fumanchu
- milestone deleted.
This won't go into 1.5. The different DB's implementations are just too diverse.
07/24/06 20:55:17: Modified by fumanchu
Database SM's now all have an autoclass(table) method, which can be used to auto-generate a Dejavu Unit class from a given table. This doesn't auto-create associations, nor does it auto-create a .py file yet.
09/17/06 06:15:37: Modified by fumanchu
- status changed from assigned to closed.
- resolution set to fixed.
- milestone set to 1.5.
I;m going to close this one and open a new one (#75) to deal specifically with referential integrity (relationships). The rest of what I *thought* this ticket was about at first is done. ;)
UnitAssociation? instances now have "nearKey" and "farKey" attributes. Is that enough, or are you asking for the StorageManager? to inform Dejavu of constraints that are present within the database but not Dejavu (i.e., in the DB metadata)?