Screencast: Stored Procedures with LightSpeed

Mindscape Screencast

In our ongoing series of screencasts, we now have a guide to working with Stored Procedures with LightSpeed.

With this screencast you will learn:

  • How to easily work with stored procedures with the LightSpeed Visual Studio Designer
  • How to work with custom parameters to your stored procedures (as OUT or REF parameters for example)
  • How to write your own ProcedureQuery’s if you don’t wish to use the designer
  • How to work with ProcedureParameter’s
  • Some tips and tricks when working with stored procedures that return projections that do not match existing entities

Click here to watch how to use Stored Procedures with LightSpeed.

We added Stored Procedure support to LightSpeed for version 2.2 (and in the nightly builds following 2.1) and supports working with stored procedures in SQL Server, Oracle and MySQL. Grab a copy of the latest build of LightSpeed that includes this support here.

Any feedback – either on the stored procedure support of on the screencast itself, is greatly appreciated. Drop a comment on this post.

7 Responses to “Screencast: Stored Procedures with LightSpeed”

  • Nice!

    I found this beauty the other day in the nightly builds and presented it this past Saturday during one of the local developer events.

    I had wondered why I was getting a FormatException when working with Projections and I should have realized that since you were deriving the custom results from Entity I needed to also return an Id. Not sure I really like having to return an Id column if I don’t need to use it, but it is a small price to pay for the functionality.

    Love the new stored procedure support.

    Dave

  • Thanks for the feedback Dave :-)

    We’re actively looking to improve the exception message when a field like Id is missing. It does seem clear once you realise why object materialization has failed but making it more obvious will help save developers time if they run into this issue.

    Thanks for covering us in your presentations – I hope you had a lot of fun doing them.

  • This is excellent, when is PostgreSQL support comming? (MySQL isn’t famous for fast SPs implementation).

    I know it is just me, but the addition of SPs will mix with all other methods/properties of uow. Are you considering putting some naming prefix to Stored Procedures?

    I know I can do it myself in the DB and name each stored procedure like SP_DoSomething, but it is now allways possible.
    So if my stored procedure is named DoSomething and I drag it to a desinger I would expect it to be renamed to SP_DoSomething (or sp_DoSomething).

    So later on I can see that I am actually working with stored procedure in the code (it doesn’t look so clear for the new guy browsing through the code).

    So it is something like “pluralize table names”, an option for the aliens like me:) would like. If there is some better way of “detecting” or “marking” the us of SPs in code let me know as it mixes with object oriented approach. And I would like to emphasize that.

    Thanks, Mindscape Lightspeed is gaining speed in features support really fast…

  • […] Mindscape Blog has a link to a screencast on using the LightSpeed Visual Studio Designer with stored procedures.  It also demonstrates the same without using the […]

  • Hello Nefajciar,

    PostgreSQL doesn’t have stored procedures but I understand that PostgreSQL functions can be used in the same way as sprocs. We are looking into supporting PostgreSQL functions and we will see if we can get this into 2.2 but no promises!

    No, we will not be adding a naming prefix to stored procedures. Application code should not care whether the GetContributions method resolves down to a table query or a stored procedure. You can of course adopt such a naming convention yourself by editing the method names in the designer, but we would recommend against this.

  • I have added runtime support for PostgreSQL functions (returning SETOF type) and it will be in nightly builds dated 30 Jan 2009 and above. We will look at designer support but this may have to wait until after 2.2.

  • This is GREAT Ivan, because PostgreSQL allows you to write SPs (ok ok functions) in your prefered language, not only in SQL. So their support is very welcomed (Postgre 8.3 just rocks!)

    Thank you very much

  • Leave a Reply

Archives

Join our mailer

You should join our newsletter! Sent monthly:

Back to Top