• Home
  • Functionality
  • Functions
  • Pricing
  • News
  • Blogs
Download
Login
Skip Navigation LinksBlogs
Follow timecockpit on Twitter

Python in time cockpit 1.7

By Simon Opelt in Category: IronPython
Sunday, January 22, 2012

With the release of time cockpit 1.7 we are happy to ship IronPython 2.7.1 as our scripting environment. This release significantly simplifies the use of LINQ by fixing an issue we identified and reported about ten months ago. It is now possible to import, transparently use and chain together calls to extension methods which LINQ heavily relies on.

Just add the following lines to your script to use methods typically required for processing .net collections:

clr.AddReference("System.Core")
import System
clr.ImportExtensions(System.Linq)

The example I previously wrote about can be simplified to look like the following:

clr.AddReference("System.Core")
import System
clr.ImportExtensions(System.Linq)

# get all projects
projects = Context.Select("From P In Project Select P")

# filter (in memory) all projects with a name beginning with T
resultProjectsWithT = projects.Where(lambda p: p.ProjectName.StartsWith("T")).ToList[EntityObject]()

# sort a collection
resultSorted = resultProjectsWithT.OrderBy(lambda p: p.StartDate).ToList[EntityObject]()

# pretty print a list of project names
print String.Join(", ", resultSorted.Select(lambda p: p.ProjectName))

# determine a minimum and maximum
print resultSorted.Min[EntityObject, Nullable[DateTime]](lambda p: p.StartDate), resultSorted.Max[EntityObject, Nullable[DateTime]](lambda p: p.StartDate)

Note that all the calls to extension methods (e.g. the use of Enumerable.Where or Enumerable.Select) can now be written as expected. The calls to ToList[EntityObject] are only required to correctly type the results for showing them in a UI result grid.

Please also note that there are still situations where the dynamic nature of Python and our data layer requires to include some type hints to determine the correct method calls but these situations are quite rare now.

  • Facebook
  • Twitter
  • DZone It!
  • Digg It!
  • StumbleUpon
  • Technorati
  • Del.icio.us
  • NewsVine
  • Reddit
  • Blinklist
  • Add diigo bookmark

Comments  4

  • Roxie 19 Mar

    No cmoplaitns on this end, simply a good piece.
  • Alex 20 Mar

    Thanks for sharing that, I nlraeed a lot about the method syntax for LINQ.I think when you have nullable types the code looks a lot cleaner if you use their .HasValue instead of checking for = Nothing. Also I think one of the areas where LINQ didn't like the nullable it just wanted you to use the .Value property. For instance I'd do it like this:If(x.HomeStoreId.HasValue, x.HomeStoreId.Value = 3111, False)Thanks for sharing your videos. I'm going to hunting through any others you have posted to see what else you've talked about. The one on super simple MVVM was quite educational for me.
  • Gautier 22 Mar

    Am working hugotrh the first module of this course and really enjoying it, but it seems it's already out of date just 4 weeks after being published Namespaces have changed so that in the introductory module the reference to three namespaces mostly require just one dll not three (System.Reactivity.dll as there is no longer a System.CoreEx.dll or the other one mentioned) A couple of using statements for new namespaces (System.Reactive.Linq and Syste,Reactive.Concurrency) also need to be used instead of those named in the course.However I'm still struggling with what the replacement for Scheduler.Dispatcher is supposed to be. It's very hard to follow along with Dan's example when the Dispatcher property used in the examples is not there on the Scheduler any more, and I can't see any replacement property that does the same thing.Is there any chance somebody could issue an addendum, or reply to this post to give some clues as to what's changed and therefore should be used instead? The changes seem to be so recent that a Google search just produces a ton of irrelevant StackOverflow posts.Thanks,Ian
  • Ian 22 Mar

    I hope that some of you especially those who are new to the Entity Framework, as I am will find this sueful tip. I showed that sometimes, especially when we try to load entity with a lot of relationships that we made in hell sql. In such a case, it may be sueful to divide the single request in a few smaller. Despite the fact that lose us some performance because these additional calls, we find ourselves with gain much more high. I also demonstrated how more on such code may be improved for better unit testing. Thank you and happy coding See A hint for Entity Framework multi-join performance problem.
Post a comment!
  1. Formatting options
       
     
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
     
     
     
       

Bloggers

  • Alexander Huber (1)
  • Karin Huber (3)
  • Philipp Aumayr (10)
  • Rainer Stropek (39)
  • Simon Opelt (5)

Categories

  • .NET (7)
  • Azure (4)
  • IronPython (5)
  • Screencasts (12)
  • time cockpit (27)

Archive

  • 2012 (1)
    • January 2012 (1)
  • 2011 (14)
    • October 2011 (1)
    • September 2011 (1)
    • July 2011 (1)
    • June 2011 (2)
    • April 2011 (1)
    • March 2011 (2)
    • February 2011 (5)
    • January 2011 (1)
  • 2010 (25)
    • December 2010 (5)
    • November 2010 (2)
    • October 2010 (2)
    • September 2010 (2)
    • August 2010 (2)
    • July 2010 (7)
    • May 2010 (1)
    • April 2010 (2)
    • March 2010 (2)

About Us  |  Legal Notices  | © 2010 software architects gmbh. All rights reserved.