Lightspeed Screencasts?

I could be mistaken but i think i saw some lightspeed screencasts in the main page several months ago, I'm unable to find them now; any help locating these (if they still exist) is greatly appreciated...

Thanks in advance

We do not have any screencasts up yet but are working on them - I'll post a small one shortly about using our EagerLoading capabilities.

Out of interest, what topics would you find useful?

Kind regards,

John-Daniel Trask

Thanks for your fast reply John-Daniel,

IMHO one of Lightspeed greatest strengths is how fast i was able to start coding my app, virtually forgetting about the boring plumbing code... i basically wanted a small screencast to pass around my team so they see this benefit as well...

I have the "Quickstart" but IMHO a screencast starting some app from scratch using the designer and seeing the synchronization and all this would turn lots of heads.

Geo

Hi,

I've created a screencasts section and uploaded an initial cast about EagerLoading (including a sample download). 

You can view it here: http://www.mindscape.co.nz/Products/lightspeed/screencasts.aspx 

I'll update this thread once I have created an introduction cast. I'd appreciate any feedback you have on the current cast in terms of quality, if you have any streaming issues etc.

Kind regards,

John-Daniel Trask

IMHO a fantastic screencast (loved the pace), no streaming issues on a standard DSL (768kbits) and cristal clear voice.

Great job man!

I was looking up eager loading. Either the screencast doesn't explain the process or I am not understanding.

Q/A

1. Eager loading - optimizes the query via object graph or you are checking to see if aggregrates exist.

2. The way I would approach eager loading is via heuristic hints into optimizing the query structure.

Please identify the benefit of eager loading, that will make me buy your product.

The benefit of eager loading is around performance.  If you, as part of your domain model analysis, know that whenever you load a Customer entity you are also going to want to load the associated PrimaryContact entity or Orders collection (because of your UI design, or because the key methods on Customer make use of those associations, for example), then you can mark them as eager-loading, and reduce the number of database round-trips.  Instead of one round-trip to get the Customer data, followed by another when you inevitably access the PrimaryContact member, LightSpeed can fetch them in a single SQL query.

This performance benefit gets magnified when you start talking about collections.  Suppose you are displaying a list of Customers with their PrimaryContacts (so you can ring them up and sell them more stuff).  Without eager loading, we are talking about one SQL query to get the list of customers; then, as each customer is displayed, another SQL query to get the contact info -- for n customers, n + 1 queries.  With eager loading, LightSpeed fetches both the customer list and the contact info for all the customers in that list in a single SQL query.  That is faster for the client and more efficient for the network and database.

You can also mark associations for conditional eager-loading, for example so that the UI can request an appropriate level of eager loading depending on how much stuff it intends to display.  This compensates for the potential performance downside where eager-loading would result in loading data that a particular screen or operation doesn't need.

So as you say it is about optimising the query by using information in the object graph.  LightSpeed makes a guess based purely on the object graph about what to load automatically and what to defer until required, but allows developers to override that through hints in the object metadata (the EagerLoadAttribute).  These hints, however, are explicit, not heuristic, because we do not know how the results of the query are going to be used.  But they are expressed at the model level and the LightSpeed engine, not the developer, optimises the SQL query structure.

Note that this is not about checking whether aggregates exist -- it is about the loading strategy (eager or lazy) for aggregates.

Does that help to answer your question?