Hello,

I am trying out LLBLGen Pro and looking for "Enum table" support (Oracle). Does LLBLGen Pro allow selected tables to act as Enums internally (and not loading the enum records as entities)?

Secondly, is there a possibility to have the generated property names from entities match the DB Column Comment, instead of its real column name?

Regards

Dome wrote:

Hello,

I am trying out LLBLGen Pro and looking for "Enum table" support (Oracle). Does LLBLGen Pro allow selected tables to act as Enums internally (and not loading the enum records as entities)?

You mean lookup tables?

Secondly, is there a possibility to have the generated property names from entities match the DB Column Comment, instead of its real column name? Regards

No, that's not directly supported (I also don't really see a usage for this, comments are for comments, not field names). You can add this via plugins which you've to write yourself.

Otis wrote:

You mean lookup tables?

If lookup tables means: Act as enumerater in code. Then yes, I mean lookup tables Maybe an example could clarify my goal: Customer table has a foreign key to CustomerType table. CustomerType table has 2 columns: ID and Description. In code, I want to see the following enum generated: Public enum CustomerType { BigCustomer = 1, SmallCustomer = 2 }

The Customer class refers (for the CustomerType property) to this enum instead of a CustomerType entity.

No, that's not directly supported (I also don't really see a usage for this, comments are for comments, not field names). You can add this via plugins which you've to write yourself.

Is there any other way to have your entity properties have different names than the according column names? Maybe you could see usage for it if you would have DBA's that restrict your column names to very unreadable/meaningless names (like we do ).

Maybe an example could clarify my goal: Customer table has a foreign key to CustomerType table. CustomerType table has 2 columns: ID and Description. In code, I want to see the following enum generated: Public enum CustomerType { BigCustomer = 1, SmallCustomer = 2 }

I don't think this is going to work if the Enum table (lookup table) gets new records inserted at runtime as then you will need to go back to the Designer to re-generate the code.

But if the Enum tables are static, and you are sure no more records would be inserted at runtime. eg. Gender table (male, female)

Then you might write your own enum and then use the enum Type Converter suggested here: http://llblgen.com/TinyForum/Messages.aspx?ThreadID=7355

Weird that this isn't supported by LLBLGen Pro out of the box. Am I the only one that creates lookup tables that are supposed to be static at runtime, just to make the database more transparent/typesafe? Or is there a better approach for that problem?

Dome wrote:

Weird that this isn't supported by LLBLGen Pro out of the box. Am I the only one that creates lookup tables that are supposed to be static at runtime, just to make the database more transparent/typesafe? Or is there a better approach for that problem?

It's not as easy as it might look. If I do: public enum CustomerType { Foo, Bar }

this is set in stone in the application. If I then change any value in the CustomerType lookup table, I get mismatches, also when I add a value to the lookup table, for example because another application on the same db requires it. I.o.w.: it's pretty fragile.

Otis wrote:

It's not as easy as it might look. If I do: public enum CustomerType { Foo, Bar }

this is set in stone in the application. If I then change any value in the CustomerType lookup table, I get mismatches, also when I add a value to the lookup table, for example because another application on the same db requires it. I.o.w.: it's pretty fragile.

Sure, but that's just a case of managing your lookup tables, right? I mean, if it's really a lookup table, there's problably some code logic like "if (customer.Type == CustomerType.BigCustomer) ...". If these tables change, the code logic probably also needs to change. So it would require a rebuild of your solution anyway, at which time you can regenerate your enums...right?

Dome wrote:

Otis wrote:

It's not as easy as it might look. If I do: public enum CustomerType { Foo, Bar }

this is set in stone in the application. If I then change any value in the CustomerType lookup table, I get mismatches, also when I add a value to the lookup table, for example because another application on the same db requires it. I.o.w.: it's pretty fragile.

Sure, but that's just a case of managing your lookup tables, right?

Sure, if no-one makes mistakes, things will go OK . The problem is that the values are actually stored at two places: in the code and in the db.

I mean, if it's really a lookup table, there's problably some code logic like "if (customer.Type == CustomerType.BigCustomer) ...". If these tables change, the code logic probably also needs to change. So it would require a rebuild of your solution anyway, at which time you can regenerate your enums...right?

I'm not denying that when everything is done as planned everything works, however reality doesn't work that way.

Now, for your convenience, someone has written a task performer for enum generation. (which is executed as a task during code generation). THis task performer was made for v2.0, but should work ok with later versions with perhaps a few modifications (source is provided). It's available to customers.

Ok. Thanks for the replies!

Dome wrote:

Weird that this isn't supported by LLBLGen Pro out of the box. Am I the only one that creates lookup tables that are supposed to be static at runtime, just to make the database more transparent/typesafe? Or is there a better approach for that problem?

Just another vote here that I would also like to see enum's as first class citizens in LLBLGen rather than every customer needing to develop their own solution.

Thanks for considering it, Patrick

Re-hasing myself perhaps: enum creation inside the designer requires data reading by the designer. We don't do that and it's very likely it will never be done: the designer reads meta-data not real data. Not only that, if the schema is empty or new, there is no data.