lsgen enhancements?

Hi,

First off, I really like everything you have done. The implementations of the UnitOfWork and LightSpeedContext are really good and I'm really liking what I see.

One hurdle I have right now that is keeping me from jumping the SubSonic ship completely is the ability to generate "clean" table names. I have tables that are named with the folowing convention: Product_Schema_TableName and what I would like to be able to do from lsgen is strip off portions of the table name. In this case, I would like to strip off Product_Schema_, so I end up with entities that are simply named TableName.

Any help or guidance is appreciated.

Also, let me add that being able to specify what tables are generated would be key as well because we use some stock schemas (like ASP.NET Membership) in our databases and I would rather not gen against them.

I have added support for stripping table and column prefixes in the lsgen command-line tool and it will be in nightly builds numbered 20080716 and above, available from http://www.mindscape.co.nz/Products/LightSpeed/nightlybuilds.aspx after about 1800 GMT.

To strip table prefixes, supply the /stp option, e.g. lsgen /stp:myproduct_myschema_.

Notes:

- This option is not yet available for drag-and-drop in the visual designer.  However you can use lsgen to create a .lsmodel file and then load this file into the designer.

- Renamed columns and tables get a [ColumnAttribute] or [TableAttribute]; it is not necessary to implement INamingStrategy.

- Only a single, fixed prefix is supported - for example you cannot say "strip any prefix of the form 'tbl_' OR 'table_'."  Stripping is case-insensitive.

- Names that do not begin with the prefixes are passed through unchanged.  For example, if you specify a prefix of "tbl_", and there is a table called "sys_SecretStuff", you will end up with an entity called SysSecretStuff, rather than an error being raised or the table being ignored.

Please let us know if you run into any problems.

SQUISH!

Man, I gotta get setup like this . . . NICE JOB!

This will also be in the next nightly.  Use the /exclude switch to specify a set of tables to exclude.  (There isn't currently an option to specify which tables to *in*clude.  This is because we expect the set of model tables to change more rapidly than the set of infrastructure tables, so we believe that an exclude list is more maintainable than an include list.)  The /exclude switch can take either:

- a comma-separated list of tables, e.g. /exclude:mytable,yourtable (don't leave any spaces between the table names; or if you do, then enclose the list in double quotes); or

- the @ symbol followed by the name of a text file containing the tables to exclude, e.g. /exclude:@excluded.txt.  The text file should contain the list of table names, one on each line.

In the unusual case that you need to exclude a table whose name contains a comma, you will have to use the list file syntax: we do not support quoting or escaping away commas in the inline comma-delimited syntax.

In both cases, if you exclude a table which doesn't exist, we ignore it; therefore you will not get an error if you mistype a table name (you'll just get a file you didn't expect).

As always, please let us know if you run across any bugs. 

Outstanding! I agree with your thoughts on the /exclude vs. the include. I'll pull the build and see how it shakes out. Thanks for your work on this! Outstanding!

Cheers!

It's working great - thank you!

I'd like to give you a little feedback on this as I've been experimenting with the lsgen stuff and since you were gracious enough to add in the functionality, I figured the least I could do is chime in with some insights to the use cases.

The exclude is very friendly for single assembly solutions. Meaning all your Entities are in one project. However, what I have found is that an include switch would be even better for multi-project solutions, where you may wish to spread your Entities over multiple projects.

In the current design, if I have a 3 project solution, and I add a table, I now have to add that table to the exclude list in 2 different locations - the 2 projects that do not include the new entity. With an include switch, I would need only add exactly what I would like to be included for the project, so I would only have to modify the project I am working on.

Also, I see that you added some functionality for stripping column prefixes. While nice to have, I personally, have not seen a need for this. But, it is in there, so there's no need to take it out, I just figured I'd let you know.

Finally, thanks again!

Thanks for the feedback.  That's a good point about where an include switch will be useful, and we'll add the feature to our backlog.

The reason for adding "strip column prefix" is that a common reason for needing to strip table prefixes is that the organisation has a standard of using a Hungarian-style naming convention, e.g. tbl_Contributions.  Organisations that use such a convention often apply it to columns as well, e.g. col_Title.  We therefore felt it made sense to handle column prefixes while we were in there.

I have added a /include switch to lsgen and it will be in the next nightly build.  Thanks again for the suggestion.

One thing to be aware of (this applies to /exclude as well): if you have two tables with a foreign key (one-to-many) relationship between them, lsgen *will* generate a parent reference in the child class, and a children collection in the parent class.  Relationships to excluded tables will *not* be removed.  Therefore you *must* include both sides of the FK relationship, or the generated code will not compile.  We feel this is unlikely to be a significant issue, but let us know if you feel differently.

Hi Ivan,

Great!

With regard to the FK relationships - good to know - but, I agree, I don't see it being a large problem. The "break" naturally occurs between schemas so I have not found this to a be a problem in my experience.

I'll pull down the latest as soon as it's available.