Location for <ProjectName>PersistentManager.cs?

Hi VP,

I am currently evaluating your DB-VA Professional product (VP_Suite_Windows_3_1_sp1_20071012) to generate C# code for .NET.

One question I have is: Is it possible to specify the location for the following generated files?:

  • DAOFactory.cs
  • DAOFactoryImpl.cs
  • PersistentManager.cs
  • ORMConstants.cs
    (I am using “DAO (with Interface)” for Persistent API when generating code)

It seems that they are randomly placed in some package, or maybe the last package I had defined (could not test this point). The problem I have is when modifying the model design and then generate code again and putting it in my already existing Visual Studio Project and then… BANG! could not find DAOFactory in namespace “…” because now that files are on a DIFFERENT namespace.

This only happens when I add or delete some namespaces. It has an easy solution (doing a massive search & replace) but it is time-consuming.

I have not tested this with the latest build, but I think this is not a bug. I should be missing something somewhere…

Many thanks

Hello distansia,

The code will be generated to namespace(s) following the package structure you defined in the project. Please inspect your Model Tree to see how your package structure is defined (see the attached image). It won’t change to generate to another namespace unless you have changed the package structure in the model.

Best regards,
Jick

orm-code-gen.png

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:
    • second
    • utils
    • utils.first

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” :wink:

Many thanks again for your support

Hello distansia,

I understand your case now. I will forward your suggestion to our team for further feasibility studies.

Best regards,
Jick

Hello distansia,

After estimating the changes we need to support the option, we decided to fix this in the next release. We will keep you informed.

Best regards,
Jick

Thank you!! :stuck_out_tongue:

Hi distansia,

This is implemented. If you want to use the function urgently, I can arrange an early access release for you.

Best regards,
Jick

[quote=Jick]
This is implemented. If you want to use the function urgently, I can arrange an early access release for you.[/quote]

Thanks Jick, but it is not urgent for me, so don’t worry. Follow your standard release plan. I have already done all main changes in the design phase of my evaluation and now the ORM support classes do not move any more.

Well, they are not located in a “logical” folder, but for my interests it does not matter.

Anyway, it is nice to see that feature implemented, you are really fast!

[quote=Jick]After estimating the changes we need to support the option, we decided to fix this in the next release. We will keep you informed.
[/quote]

Hi Jick,

I understand that this feature will see the light on the DBVA 4.1 sp2 or maybe 4.2 ??

I have just downloaded the 20071116a version you have just prepared, and is this feature in it? I have not found where (?).

Don’t worry about that for me, if it is scheduled for release in 4.1 sp2 or 4.2 it’s ok (by the reasons previously indicated). I only wanted to know if it is on this release (20071116a), and if so, where and how to use it.

Many thanks again

Hi distansia,

Thank you for your concern. The change will be available in version 4.1 sp2 or 4.2 (haven’t yet decide the build number). In other words, you will not see the change in those hotfix releases.

Best regards,
Jick

Hi distansia,

Glad to inform you that your request was granted by allowing the selection of Persistent Manager Package. You can try this feature in the latest version. Hope you find it useful.

If there is anything else that I can do to help please do not hesitate to ask.

Best Regards,
Jick

generate-orm.png