Home » Blog

Archive for March, 2009

Enhancements to LINQ provider for LightSpeed 3.0

In LightSpeed 2.0 we introduced support for LINQ queries through our LightSpeed LINQ query provider (Mindscape.LightSpeed.Linq) which has been universally appreciated by our customers; however we have heard from customers who wanted to write some fairly sophisticated queries and found that our LINQ provider has some restrictions and omissions – notably support for explicit joins, groupings and certain type of set operators.

The LINQ provider in LightSpeed 2.0 was all about translating LINQ expressions back against our existing query API. In LightSpeed 3.0 we are extending the query API to support these additional scenarios and to that end we have added in support for join’s, groupings, multi-part traversals and better support for translation of functions that you would generally expect to work.

Can you just make it so any query I write will just work?

The job of our LINQ provider is to translate an expression which you have expressed in code into a query against the underlying data source in a sensible way to return you the correct result – which some times may be an entity, a collection of entities, or even a projection to a totally new type. You are also allowed to chain queries, such that you could select a collection of entities and project them to a new set, then transform that set, then select a subset of that query, filter it and then project it to a new set (and so on) – so while its perfectly valid for you write that query, translating that to a sensible query for LightSpeed may tricky or even may not be possible at all.

When an expression is defined, we first need to translate that into its client and server components – where a server component is something we can execute against the database, and the client side part is something we need to do in memory using LINQ to Objects. Why? Because it might not be possible for us to have the server actually do all the work which you expect. A simple example is where part of your query contains a property on the .NET class rather than being against a database column – to handle these we either need to translate this property into something which can be extrapolated from the underlying database row data or we have to evaluate the property once the object has been bought back into memory.

Currently we throw exceptions where we encounter a situation we cant directly handle, rather than fetching the server component and doing the rest in memory – you can always get around this by forcing the results to be evaluated by calling .ToList() or the like, but the reason we do this is to avoid situations where you might end up writing a query which selects a Cartesian product and then has to do the rest in memory – in general we think we should be continuing with this approach – what do you think?

Calling all LINQ queries!

Do you have a query you want to see serviced by LightSpeed 3.0? If so, email us a small sample of your model and the query (which should currently fail!) or post it up in our forums and we will add it to our test suite. While we cant guarantee to support everything for the reasons I mentioned above, we will be working hard to make sure everything that is sensible is supported and we would love to hear your thoughts on this matter :)

Feedback wanted on potential licensing changes

With the upcoming release of LightSpeed 3.0 we’re planning to review our pricing and licensing scheme. This is something that we want your feedback on.

What we have today

Currently, LightSpeed is priced per organisation that owns the solution IP. This is a phenomenal value – comparing us to virtually any non-free competitor and LightSpeed will likely save you hundreds, if not thousands, of dollars despite having a fantastic feature set.

For example, currently you could use LightSpeed for free, or grab the most highly priced version – $499 USD for your organisation and includes source code.

What we’re proposing

We will likely be moving to a model that mirrors how developers expect to see development tools priced – per developer seat.

We will also be setting up a subscription service for folks who wish to renew their license to get new major upgrades for 12 months. Currently when you purchase a license you’re entitled to free upgrades of point release, but not for major releases. Clearly this is not ideal if you purchase just before a major release. In the past we have offered heavily discounted upgrades to customers who recently purchased (something we don’t have to do, but we all feel it’s the right thing to do).

Why are we planning this?

There are plenty of reasons:

• Lower initial pricing was to reflect that LightSpeed had some gaps however this has now changed and we hold our own, or beat, most competitors in a feature by feature comparison
• Pricing per intellectual property holder is confusing to a lot of people. We have to explain the licensing to many purchasers who do not find it clear.
• We’re a small company – when we have to clarify to a customer that they do not need to buy 10 licenses it hurts us financially. We have never just let them purchase 10 because they don’t understand the license – it’s not our style.
• More and more people think our pricing is per seat – it’s the expectation for the value being delivered by LightSpeed
• We’re too cheap – at various trade shows and in discussions with developers they assume something must be missing or wrong for the pricing to be so low.

Existing customers

If you’re a customer, your current license will not be changing for the LightSpeed 2.x line so this is not a concern for you.

Once LightSpeed 3.0 is released we’ll contact existing customers and offer them the ability to perform a “renew subscription” type function that will likely be well below the retail price but provide them access to LightSpeed 3 and above. To be clear here – it would be a fantastic time to purchase LightSpeed now if you have been thinking about it.

What do you think?

Currently this is just our current state of thinking. Many of you are our customers or potential customers and we value your input on this. Pricing and licensing is a very hard problem for a business to get right and we appreciate any feedback that you have on these ideas. Your feedback will directly impact what we end up doing with licensing and pricing in the future.

Extra credit: Would there be any interest in Mindscape providing a subscription based set of all our software? LightSpeed, WPF products, SimpleDB Management Tools + whatever new products we release for one price per developer?

Staff blogs are up!

A quick post to let readers know that if they would like to keep up to date on the happenings of various members of the team here at Mindscape that they can do so now on the staff blogs page.

Jeremy’s blog can be found here
Jeremy writes about all sorts of Microsoft stuff – currently he’s writing a lot about Microsoft ASP.NET MVC and he’s known for covering topics relating to SQL Server.

John-Daniel’s blog can be found here
My blog tends to cover more of the business aspects of Mindscape although occasionally some technical bits will appear in here.

Ivan’s blog can be found here (not on the Mindscape site)
Ivan covers everything from his experiences with Scala.NET to the water level of the stream that runs behind his house :-)

I’d like to grab a plug-in that integrates just short slugs to the posts from these blogs into the main feed for the site since the posts are normally technical. I appreciate any feedback if anyone knows of such a plug-in for WordPress :-)

LightSpeed 3 and .NET 3.5

In versions 1 and 2 of LightSpeed we consciously chose to keep the core framework compatible with .NET 2.0, adding 3.x features such as LINQ and Dynamic Data only via additional libraries. With the increasing deployment of .NET 3.5 and .NET 3.5 SP1 (or “.NET 3.8″ as we are not allowed to call it), and the data-related features in those releases, we’re having to re-evaluate that baseline for LightSpeed 3.

The reason is that some of the features we’d like to support require us to implement interfaces or attributes against core classes such as Entity or EntityCollection. For example, suppose we decided that we wanted to implement INotifyCollectionChanged on EntityCollection as part of improving WPF support, or to implement INotifyPropertyChanging on Entity in order to facilitate user undo mechanisms. We couldn’t add these features via an add-on library: the interfaces would have to be on the EntityCollection or Entity classes in the core framework. Which means the core framework DLL would incur a dependency on .NET 3.5 SP1.

On the other hand, not everybody’s using .NET 3.5 SP1. Enterprise environments in particular can be slow to adopt new versions of the framework, and requiring the latest version can incur resistance from IT administrators. Mono users enjoy a pretty complete 2.0 feature set and some 3.5 features, but not everything. Obviously people in those environments won’t be able to use features that depend on 3.5 SP1, but we’d like to have a graceful degradation path, so that they can still use the many features of LightSpeed that don’t depend on the latest framework version.

So here’s our current plan. We’re going to bite the bullet and take the 3.5 SP1 dependency in the core. This allows us to move forward with things like WCF support, ADO.NET Data Services, etc. which are troublesome or impossible to do in add-on libraries.

But we’ll also ship a 2.0-compatible version of the LightSpeed DLL. This will be built off the same codebase as the main assembly, but with 3.x-specific dependencies removed so that it can be used in a 2.0 environment. We expect that the compatibility build will be feature-complete relative to the main assembly, except that it won’t be usable with 3.x-only technologies.

Furthermore, where we can ship 3.x features via add-on libraries, we still will. So, for example, LINQ support in LightSpeed 3 will still be provided by an additional assembly, rather than baked into the core. This isn’t technically strictly necessary, but it makes it easier for us to maintain the 2.0 compatibility build — less stuff to #ifdef out!

We think this is the best way to allow LightSpeed to move forward with the new capabilities of the .NET platform while still maximising reach for more conservative deployment environments. We recognise a couple of downsides: potential confusion over having two builds of the LightSpeed DLL, and a lack of granularity (it’s an all or nothing choice of 3.5 SP1, the latest version of the platform, or 2.0, which is pretty long in the tooth).

We’re always keen to hear feedback from users, so please let us know your thoughts on this. What framework versions are you targeting now? Would a 3.5 SP1 dependency be a dealbreaker for you? Do features like ADO.NET Data Services justify jumping all the way to SP1 or should we make 3.0 or 3.5 our primary target? Would a compatibility build be useful for you? Tell what you think in the comments!

LS3 Enhancement: No uninstall needed

Just a short post about one of the small enhancements that have just been committed for LightSpeed 3.0 – automatic uninstall of previous versions when running the installer.

This might not sound like a change worth mentioning but for those of you grabbing nightly builds to try out new features or get a bug fix, it will be super helpful. Previously you would have to go and uninstall the previous version via the add/remove programs control panel applet which was always a bit of a hassle. We always try to do as much as we can to remove frustrations and time-sucking aspects of a developers life so decided it was time to streamline this process.

Now the installer will check for any previous install of the current major version and remove it and proceed to install the new version.

I’ve pushed this up to the 2.2 nightly builds to ensure that it’s rock solid for 3.0 but so far our testing shows it’s working well. If you grab the newest nightly you will require to do one last manual uninstall and then it should be smooth sailing for future nightly builds.

We will also roll this out to our other products in a few weeks. Let us know if you have any issues :-)

Happy coding!