LightSpeed.MetaData, coming in LightSpeed 4

LightSpeed MetaData is crazy delicious

I’m pleased to announce that we’ve just shipped our last functional enhancement release for the LightSpeed 4.0 release and it includes the last major feature addition: LightSpeed.MetaData.

Blimmy, what’s this all about then?

Over the years we’ve had consistent requests from our users that they’d like to be able to access the LightSpeed Meta Model. This gives developers the power to access the entity models, field models and other interesting stuff that we keep tucked away. Typically, keeping things tucked away is a good thing as it keeps LightSpeed easy to learn and not too intimidating for the common use cases which is why we’re implementing this in a different assembly.

With LightSpeed 4 we will be shipping a new assembly: Mindscape.LightSpeed.MetaData.dll

From this library developers can use handy extension methods to pull out information about an Entity. This means three things:

  • No need to write messy reflection code to access our internal model
  • No need to worry that we might change something internally and break your code
  • You now have even more ways of doing crazy cool stuff with LightSpeed.

What does the API look like?

Currently the API is nice and simple. We have implemented the MetaData capabilities through Extension Methods so the first thing you’ll need to do is add a reference to Mindscape.LightSpeed.MetaData.dll and then add a using statement:

using Mindscape.LightSpeed.MetaData;

Once that’s done you’ll have an extension method on any entity:

      Car car = new Car();
      EntityInfo entityInfo = car.EntityInfo();

Easy as that. From the EntityInfo object you can access information such as if SoftDelete is enabled, if Versioning is enabled, if CascadeDeletes are enabled and more. The interesting thing is that you can also walk the fields off an entity and inspect their information such as type, if they’re associations, read only status etc.

What would I use this for?

It really depends on your situation if you’d find a use for this capability. For example, in LightSpeed 4 we will be shipping an EntityModelBinder for ASP.NET MVC that is built using the LightSpeed.MetaData library so that we don’t need to rely on ugly reflection. We also have developers who want to do perform generic cloning operations who would find this useful. This is why we’re excited to see what people do with LightSpeed.MetaData – the only limit is on your imagination.

Right, so how do I get my hands on this?

LightSpeed 4 Beta is available to all LightSpeed customers who have active subscriptions right now. You can download it from your store account.

If you’re waiting for LightSpeed 4 to ship before purchasing then don’t – grab a LightSpeed 3.11 license and you’ll get updated LightSpeed 4.0 release on RTM.

Tagged as Beta, LightSpeed

12 Responses to “LightSpeed.MetaData, coming in LightSpeed 4”

  • Can you add a property at run-time and upgrade/migrate the database to contain the column that is implied by that property? Meaning can run-time entity design be performed and kept in sync with the database…

    Thanks

  • LightSpeed entities are .NET classes. As such they are compiled and cannot be modified at run-time. The metamodel reflects this: you cannot add properties at run-time. (And really it wouldn’t be very useful if you could, because your code would have no easy way of addressing those properties.) What you can do is, as you add properties in the designer, create migrations to add the corresponding columns to the database. You can host migrations within your own program to ensure that the database is always in sync with whatever version of your entity model the user is using.

    If this doesn’t meet your requirement, could you say a bit more about what you’d like to be able to do and how you envisage it working? Thanks!

  • Run-time entities… interesting idea and seems possible using Emit to dynamically create and save an assembly containing entities at run-time. I’ve been trying to imagine a reason when a why someone would want to do this. It’s definitely outside of normal development. I can envision something like this being useful in some SaaS situations where end users, rather than developers, are defining a system. I find it an interesting idea from an academic standpoint, probably little reward in terms of ROI however.

    Anyway… good news on the MetaData.

  • I’ve used the Emit trick in a situation where I wanted to use LightSpeed to load data without requiring users (who were in this case developers) to write fully-fledged entities. The idea was that the user could just define an interface, and behind the scenes the interface gnomes would spin it up into an entity. However, this was very different from TJ’s scenario: the entity properties were still defined at compile time via the interface, and the runtime aspect was just building an implementation.

    The SaaS example is an interesting one though. You could indeed use Emit to create an entity class from a user-defined list of fields. And with that in place it might indeed be useful to load and instantiate entities and get and set properties by name using the metadata API. (At least hypothetically. The metadata API doesn’t currently support instantiating entities or setting entity properties. But we can add these features if people would find them useful.) However, it would be unusual to create a custom database schema for each client in a SaaS situation. I’m intrigued to hear if TJ’s scenario is along these lines and if so what we can do to support it…

  • Hi again,

    I have a product that allows a user to determine an arbitrary (valid) database query which returns a certain schema. Then using the columns in that schema the user can manually add “calculated” columns (based on a valid expression of the base query columns) to extend the dataset. All of this is stored as a named dataset definition which can be run at any time, that first runs the query then adds the extra columns by applying the field rules. I built this all using Telerik OpenAccess’ run-time metadata extension api. Incidentally they built that API in order to be able to support their CMS product which allows the definition of objects and properties at run-time.

    I have been looking at moving my product to a different ORM for a while now and have been eyeing Lightspeed and this is why I asked the question.

    There are many many usecases for such a feature. Any system that allows a user to flexibly create their own definition of some data structure that needs to be persisted is a candidate, just like my product.

    I hope this helps in terms of the use case.

    Best

  • Thanks TJ, that’s great information. Unfortunately this is beyond the scope of what we plan to do in the first drop of the metadata API. That said, I don’t think it would be too hard to create simple entity classes at runtime using Reflection.Emit or CodeDOM (the main thing to watch out for is associations). The core (non-LINQ) query API allows weak-typed query building so that would allow queries on the dynamic fields, and the metadata API would allow you to get the values from those fields. The current drop of the metadata API doesn’t support updating entities but we’ll almost certainly add that before RTM. Calculated columns might be a bit trickier and I am not sure I understand the behaviour you need but this could probably be done by translating the user-specified expressions into LightSpeed function expressions e.g. Entity.Attribute(“Salary”).Function(“*”, Entity.Attribute(“YearsOfService”)).

  • The Metadata library sounds interesting. Just curious.. I know LightSpeed currently uses System.Reflections internally to query the classes, in the future will you be moving away from that and instead rely on your own Metadata library? Or does the Metadata library in turn rely on Systems.Reflection?

    The reason I ask is because most shared hosting providers don’t allow Systems.Reflection, and enabling ‘Medium Trust Compatibility’ comes at the cost of performance offered by Systems.Reflection. Which brings me to my next question: How does the Metadata library compare in performance to System.Reflections? Thanks.

  • LightSpeed internally uses System.Reflection to construct its internal metamodel. The metadata library sits over the internal metamodel. So yes, LightSpeed will still continue to rely on Reflection. However, the metadata library doesn’t rely directly on Reflection: it uses the cached metamodel from the LightSpeed internals.

    We haven’t tested the performance of the metadata library versus Reflection, but I think it would be slightly faster because it uses LightSpeed’s cached model and (in full trust) fast field accessors. But as always, if performance is critical, don’t trust me, measure!

  • […] since JD unleashed LightSpeed.MetaData on an unsuspecting world, we’ve been inundated by people asking about the possibility of declaring entities at […]

  • […] LightSpeed 4, and the shiny new LightSpeed.MetaData […]

  • Hi just wanted to give you a quick heads up and let you know a few of the pictures aren’t loading correctly. I’m not sure why but I think its a linking issue. I’ve tried it in two different web browsers and both show the same results.

  • Thanks for the heads up, apocalypse — I think this may be a CDN issue as I did see the same issue but refreshing the page fixed it. I’ll let our Web folks know though — this isn’t the first time we’ve had problems with the CDN. Thanks again!

  • Leave a Reply

Archives

Join our mailer

You should join our newsletter! Sent monthly:

Back to Top