Hi Jick,
Yes, you are right about that example. But I tell you a little bit complicated one.
In my experience, I have found that DBVA uses the FIRST package you create in a project’s lifetime to store the “persistent support files” (DAOFactory.cs, DAOFactoryImpl.cs, xxxPersistentManager.cs, …).
Now, this would be fine if you know this (or the program warns about it) and the first package you create in your model is named, i.e.: “ormsupport”.
But, what happens if you later decide to move that package inside other called, i.e. “utils” ? sometimes your support files will be correctly generated in utils\ormsupport but sometimes not… ending in an apparently random namespace. I think the problem is that the program tries to put them on the first namespace it has in its inside data model for the project file, but this is not our matter.
Well, you can reproduce this “phenomenon” following EXACTLY this steps:
( tested with last ‘stable’ release: VP_Suite_Windows_3_1_sp1_20071018 )
- Create new project
- Create new root package, and call it “first”
- Create a new class inside of it, call it “cls1” and add ORM Persistable stereotype
- Go back and create a new root package called “second”
- Again, create a new class inside of it, call it this time “cls2” and add ORM Persistable stereotype
- Ok, save your model, sync to ERD, DON’T SAVE project after this, and generate code.
The persistence support files are nicely placed on “first” folder.
- Delete all generated code now (to be able to compare later)
Ok, REOPEN your saved project before the ERD Sync and:
- Create a new root package and call it “utils”
- Move the “first” package inside of “utils”
- Your model should be:
Now, sync to ERD again and generate code.
Voila! the persistence support files are now placed on “second” folder!! :x
This is a very simple way to show this “bug/feature”, but rest assured I did not find it this way. It showed me with a real life project I’m using to evaluate your product with multiple packages and classes.
This simplified way will serve only to surface you the problem, following only a few steps.
I think that it would be great to add an extra parameter to the ORM Code generator to set “namespace to put persistence support files”, and then placing them all together in that namespace. Them would be no problems like these never.
BTW, maybe are you wondering why I forced you to DON’T save the project after sync to ERD. This is my standard way of working with your program, because when I sync the model to ERD, “ID” fields are added to every class, and later on if I change some class location, delete some of them, create some other new classes, modify association, … then some classes have “IDs” and some other doesn’t. If I check “create ID for all classes” when re syncing to ERD, the ones that already had one, now will have two (one unused for associations), and so on…
So I save my project, try Sync-ERD+Code generation, and then discard that “erd synced” project. I have found this process to be optimum for me. Or… maybe can I suggest another “nice to have” feature consisting of “remove ID fields from all classes” 
Many thanks again for your support
