This question is locked. New answers and comments are not allowed.
Hi all,
Just started looking at the Fluent API docs and ... as an self-respecting newb ... ran the example (and there was much rejoicing).
Now ... as a dedicated hack ... I decided to start playing with the example class ... and added and removed properties ... and reran ... expecting to see the table change to my evil design (and there was much head scratching).
I noticed that the sql dbase table generated reflects the same structure as the original ... even though the class has been altered significantly.
Is there just something I am missing? Deleting the Dbase completely and rerunning comes up with the exact original table. Obviously - something is persisting and I lack the technical knowledge to know what to slay and how to slay it. Anyone have a rftm link to this ...
i.e. some metadata file generated somewhere that one must clean up as part of the process of violently changing the class to make the new table reflect the new mappings.
In terms of source code ... it is the exact same as the example. Just curious ... since it does seem quite useful early in a project when there is great entrophy to have the code first approach automagically keep up with the entrophy without delving into the need to go mucking in the dbase ...
Just started looking at the Fluent API docs and ... as an self-respecting newb ... ran the example (and there was much rejoicing).
Now ... as a dedicated hack ... I decided to start playing with the example class ... and added and removed properties ... and reran ... expecting to see the table change to my evil design (and there was much head scratching).
I noticed that the sql dbase table generated reflects the same structure as the original ... even though the class has been altered significantly.
Is there just something I am missing? Deleting the Dbase completely and rerunning comes up with the exact original table. Obviously - something is persisting and I lack the technical knowledge to know what to slay and how to slay it. Anyone have a rftm link to this ...
i.e. some metadata file generated somewhere that one must clean up as part of the process of violently changing the class to make the new table reflect the new mappings.
In terms of source code ... it is the exact same as the example. Just curious ... since it does seem quite useful early in a project when there is great entrophy to have the code first approach automagically keep up with the entrophy without delving into the need to go mucking in the dbase ...
3 Answers, 1 is accepted
0
Hello Rich,
Petar
the Telerik team
Currently OpenAccess does not allow you to drop no longer used elements in the database. This is done with the presumption that even though OpenAccess is not using a given part of your database model this does not necesserilly mean that this part is not needed at all. Unfortunately there is no way that you can instruct OpenAccess to always drop tables and columns that are not mapped at the moment.
Can you please share with us how important is that for you?
Petar
the Telerik team
OpenAccess ORM Q2'12 Now Available! Get your hands on all the new stuff.
0
RICH
Top achievements
Rank 1
Rank 1
answered on 25 Jul 2012, 05:08 PM
To be honest - that is exactly the way it should behave in the final use case. i.e. do not alter things that go away. Now that I realize the side effects would be catastrophic in production ... it seems easier to do this via a change to the test bench and the test plans.
It would be VERY bad for the API to remove columns from an existing table in our use case since our use case is to have the Dbase be intelligent enough to know when the new object is present and adjust itself to take the new object. And, of course, not break the legacy systems at all.
So the answer - to the question (How important is this to me?) is: Not Important at all. I much prefer the behaviour provided. I would rather redesign my test environment to clean up things versus letting the API do it for me.
This issue is only an artificiality of the dev environment and can easily be solved with instructions to the team to clean up tables between Continuous Integration runs. In this way - we can always get the fresh table the way we expect it.
After all - the second the code goes to the first release and is branched ... the next generation of tests will demand that the original columns are unaltered (and the new columns are present).
In this case - we failed a test ... but failed it for the right reason.
I would rather change our environment to be smart enough to delete tables between CI builds versus giving me the options to destroy columns at will. I can see the horror that would inflict on terabytes of data and consider it a very wise move "not" to allow me the power to do something this destructive (Murphy's law being a universal constant).
I think this thread can close with a happy ending. It is unwise to do it any other way than the way it is presently done. Thanks for the response.
It would be VERY bad for the API to remove columns from an existing table in our use case since our use case is to have the Dbase be intelligent enough to know when the new object is present and adjust itself to take the new object. And, of course, not break the legacy systems at all.
So the answer - to the question (How important is this to me?) is: Not Important at all. I much prefer the behaviour provided. I would rather redesign my test environment to clean up things versus letting the API do it for me.
This issue is only an artificiality of the dev environment and can easily be solved with instructions to the team to clean up tables between Continuous Integration runs. In this way - we can always get the fresh table the way we expect it.
After all - the second the code goes to the first release and is branched ... the next generation of tests will demand that the original columns are unaltered (and the new columns are present).
In this case - we failed a test ... but failed it for the right reason.
I would rather change our environment to be smart enough to delete tables between CI builds versus giving me the options to destroy columns at will. I can see the horror that would inflict on terabytes of data and consider it a very wise move "not" to allow me the power to do something this destructive (Murphy's law being a universal constant).
I think this thread can close with a happy ending. It is unwise to do it any other way than the way it is presently done. Thanks for the response.
0
Hi Rich,
Petar
the Telerik team
We are happy that you are also sharing our vision of how our product should behave in such scenarios. We have always been driven by the fact that the customers data is of utmost importance to us and dropping some artifacts from the database might prove extremely problematic.
Please do not hesitate to contact us back should you have any further questions.
Petar
the Telerik team
OpenAccess ORM Q2'12 Now Available! Get your hands on all the new stuff.