Generate database from model outside of designer

Is there a way via code or command line to generate the database if you have chosen to take the designer-less route.  Basically a manual way to invoke the right click -> update database command? 

Could you clarify what you mean by "the designer-less route"?  Are you thinking about creating a .lsmodel using the designer but wanting to update the database from the command line (e.g. as part of an automated build process), or were you wanting to update the database from some other source (e.g. handwritten class definitions)?

(Neither of these is possible at the moment, but I'd like to understand the scenario so we can see what it would take to add the functionality.)

Thanks Ivan, I was actually trying to figure out what the story is for both of those scenarios, I just wasn't being clear. 

I was wondering what I might do if faced with the prospect of decorating existing classes with LightSpeed attributes (handwritten clases), and then what my database generation options were (during a build / test process) afterwards.

I would ideally like to see something similar to the SchemaExport class that NHibernate offers as an API to do this.  This way, integration focused unit tests could have a setup / teardown that created a database for the sake of testing.

We haven't tackled extracting the metadata from existing LightSpeed classes written in C# or Visual Basic, though we do obviously have a lot of relevant code already within LightSpeed which we could leverage.  I will take a look at whether we could quickly create a schema export tool from this.

As for the other scenario, updating the database from a .lsmodel file using the command line, we could probably implement that reasonably easily.  One reason, however, that we've avoided doing this so far is that it's not unusual for updating to require a bit of manual attention -- our update engine has some limitations and sometimes it can't do things, or needs two steps to do them.  (These same limitations would probably affect any sync utility that ran off handwritten classes, because it would use the same underlying engine.)

A possible alternative strategy in the .lsmodel case is to use the new "Log SQL" feature to capture the generated SQL.  You can then by hand make any changes necessary for it to become completely automated, and put the results under version control for use by the integration tests / continuous integration server.

We plan to have some major improvements in this area as part of LightSpeed 3, though we currently plan to integrate these only with the visual designer rather than with handwritten classes.  We are of course open to feedback on this!

Improvements in this area would be welcome Ivan.  I'm heavily evaluating this product for my team and I really appreciate it's quick learning curve and ease of use as compared to some other products.  It handles many scenarios that are the 80% to 90% cases if you by convention are staying out of some of the more exotic areas of some of the other more full featured tools in the ORM space. 

That being said, in my evaluation, the designer story feels like it starts to degrade fairly quickly in a domain first scenario.  It may be more preference oriented than anything, but the solution starts to get a bit disorganized when I create new files for things like enums that I can't see or use in the designer, then on top of that, add partial classes to contain behavior.  It becomes an effort for developers to consistently find where classes are defined in files.  Then on top of that, there are situations (like value type attributes) where the designer gracefully refuses to generate my corresponding database schema. 

I think improvements aimed at upgrading the designer to handle custom types like enums (I know it already handles non-persistent classes), improving value type mapping, and upgrading the database generation tool would be well worth it.

Alternatively it seems as though it might be easier (and I would actually prefer this) to expose a tool that allows me to use my hand coded classes (marked up with LightSpeed attributes) as an input to a SchemaExport tool that generates DDL or optionally executes it against a database.  This way, I get to fully own my hand-coded classes, I get to co-locate behavior and state concerns within my domain objects and I get the benefit of having them be persistable as long as I use the LightSpeed attributes and follow the right conventions.

In the case that the designer ever did catch up to what can be done manually outside of it, it would be great to have the ability to drag in class files into the designer (not unlike what the native VS class designer offers).

 Thanks for listening!

Just to update you on this, I did some prototyping on this yesterday and I think the database update tool could be a goer.  The difficulty with dragging class files into the designer is that there is a lot of detail (e.g. all the validation types) and quite a few potential edge cases, but these shouldn't be such an issue for a database update tool, as the subset of features that affect the database schema is much smaller.

I'm not saying we're close to offering such a tool / toolchain, but we may (no guarantees!) be able to provide something basic in the next few weeks and then iterate with you to round out the feature set.  Is this something you'd be willing to work with us on?

Also, to reiterate, such a tool would incur many of the same limitations as the designer -- for example, it would not currently handle value objects, which is obviously a concern of yours.  (This specific limitation is simply a resourcing / priority limitation, not a deep technical limitation, and could probably be addressed as part of the tool work.)

I would definately work with you on this.  I think it is a key feature for model first development.

Hello Aaron,

Sorry this has taken a lot longer than I anticipated due to other projects; hope this is still of interest to you.  The nightly builds now include two command-line utilities, which you can use together to perform a database update from handwritten C# or VB classes.  Please note that these are currently in very rough form -- there is pretty much no error handling, some features may just not work, the command-line interface needs tidying, testing has been very limited, etc.  The two utilities are:

lsgetmodel.exe: analyses a compiled assembly and generates a .lsmodel (designer) file for the entity and value object classes

lsupdate.exe: updates a database schema to match a .lsmodel file (like right-clicking in the designer and choosing Update Database)

By running these two in sequence you can therefore update a database from your compiled DLL or EXE.

The syntax you need will be as follows:

lsgetmodel MyModel.dll temp.lsmodel
lsupdate temp.lsmodel SqlServer2005 "Data Source=x;Initial Catalog=y;Integrated Security=true" sql.log

In the lsupdate command, the possible values for the database type are the LightSpeed DataProvider enum names e.g. MySql5, Sqlite3.  The SQL log file is optional: if present please note that it acts as a log, not as a script: the update is still applied directly to the database.

Also note lsupdate operates under the same limitations as the designer: specifically it cannot create an association in the same pass as creating the table (so you may have to run it twice).  On the plus side, I have now added support for value objects, which I know was of interest to you.

Finally, to reiterate, these are very much first cut code drops: there will be bugs and they will probably not be handled very elegantly!  Please be patient and let us know what problems you run into!