All--
Please help.
How can one change the DBO and then Refresh?
Right now, it looks like LLBLGen will drop the previously mapped Entities and TypedLists because the DBO does not match so the mapped object has nothing to be mapped to, or so the Refresher seems to think. That is, the actual schema (the tables and views and stored procs) could be exactly the same but because the DBO has changed, the Refresher will drop all entites and TypedLists.
It looks like this is an issue.
Why? Well, because information can be lost that could (perhaps?) otherwise have been preserved.
Let me explain what I mean.
Well, first, it is not really an issue for Entities IFF one uses the mapped entities out-of-the box. That is, if one does not tweak the entities at all, then one can just recreate them. This is fine for someone like me who does not tweak the mapping specification at all. However, if one does tweak the specification, then what I say below applies not just to TypedLists but also to Entities.
The problem comes with TypedLists. These are toast and need to be manually recreated. Why? Well, if the Entity is dropped, then the Refresher has nothing to map to the TypedList and it says "sorry, nice to see ya, wouldn't want to be ya". Ug. That's harsh.
Since, I think that LLBLGen would be imroved by addressing this, I will offer what I believe are some ways to enhance the product. How can this be handled? Well, maybe there are a few ways to go.
(1) One way would be for the Refresher to get a bit less algorithmic and get a bit more heuristic. That is, it would need to "guess" and "look for" a match to the entites before it kills them. That might be tricky; but, it could be done.
(2) Another way would be to have an "ignore DBO" switch in the Application-Preferences and/or the Project-Preferences. This might be the easiest way to go and, from an enduser's perspective, it might be the most enduser-friendly.
(3) Another way would be to make TypedList specifications disconnect from the Refresh. They would be "broken" but the could be "reattached to entities as-needed". This would be tricky; but, it could be done.
(4) Another way would be to make TypedList specification importable/exportable to/from one LLBLGen project to the next. They might be "broken" upon import; but, as in (3) above, they could offer a way to be reconnected to entities. Again, this would be tricky, but it could be done.
Well, that's it for ideas for now. I hope this helps.
FYI, for the time being, I need a workaround. I was very excited about using TypedLists on this sub-system. I think they are a great idea and they are very powerful. I had chosen them over TypedViews because, as far as I know, TypedLists are updatable and TypedViews are not. Therefore, I was choosing TypedLists because they are the more powerful/flexible solution over the 2. However, now given this destructive natrue of the Refresh processing, I am now going to use TypedViews and not TypedLists because I can always regenerate them as-needed. TypedLists take some time to create and they are not easy to regeneate whereas Views live in the DB init script and can be remapped at the press of a button. I will have to use TypedViews for ReadOnly and then pull them apart at runt-time and persit entity-by-entity; but, that's not so bad.
(Caveat-- I realize that this case may be rare. Perhaps it is virtually always the case where the DBO will not change. That's fine. I understand that that is what most people probably see. However, being a contractor, I have zero control over this kind of thing. I may not be informed about a DBO change until it is too late. Furthermore, I have found that corporate environments often have some very strange policies-- so, DBO may be set at the content of a strange DBA. One small example of this strangeness is a contract that I had where they gave us development database BUT we were NOT given rights for Profiler. Therefore, for now, I think that I will try TypedViews. And so on.)
That's all for now.
What do you think?
Please advise.
Thank you.
--Mark Kamoski
