Corey Roth and Friends Blogs

Group site for developer blogs dealing with (usually) Ionic, .NET, SharePoint, Office 365, Mobile Development, and other Microsoft products, as well as some discussion of general programming related concepts.

Not Necessarily Dot Net

June 2008 - Posts

  • Linq to SQL Designer Weirdness

    The Linq to SQL designer that's built into Visual Studio 2008 is pretty, and a huge improvement over what Microsoft's provided before, in terms of data modelling.  I haven't used enough other OR/M's to really have an opinion about how it measures up to other products.

    But it does have its issues.  For one thing, it seems to magically cache its schema somewhere internal.  So you better have your database design pretty much set in stone before you start actually doing any data access.  (Yes, I know.  Have your product designed before you start writing code.  For some small projects, especially when the real point to them is to learn a new technology, design-as-you-go and incremental development have their place).

    But that isn't the point.  If you change (by this I mean add/remove columns) your database schema after you do the drag-and-drop thing to have the designer generate the data access layer code for you, the only way I've found to get that data access code to match your changes is to update the generated code by hand.

    This,  of course, is a Bad Thing (TM), Should Be Avoided At All Costs, and is a general pain in the ass.  But even deleting the table from the designer, rebooting, and re-adding it didn't work for me.  (I didn't go so far as to delete the DBML file, because I've spent several hours tweaking it...maybe that would work).

    Actually, tweaking the dbml by hand isn't that big a deal.  Just tedious, because you have to change several things in several different places, and the compiler errors are useless if you forgot to dot a t or cross an i.  But the designer has an annoying tendency to want to overwrite your changes, so use caution.  (It's so much easier to not actually look at your changes with TFS...)

    Sometimes, though, even that isn't enough.  I realized at one point yesterday that  a bigint field in the database really should be an int, to match up to where that field connects to everything else. So I changed it, then dutifully changed the matching dbml.

    Then general distractions slipped in.  By the time I got done juggling and back to testing that change, I'd really forgotten about it.  And got a "Specified cast is not valid" SystemException (not an InvalidCastException as I'd expect) every time I tried to query that table.

    I verified the data types of all the columns (especially the bigint vs. int). Did everything I could think of to get it to regenerate it with the correct column types.  Finally, out of desperation, I switched the column specifications in the dbml (OK, you can do this with the designer) back to long/bigint.

    And it started working again. I think this is the first "just let VS 2008 magic, even though it's blatantly wrong" thing I've run across, but I really haven't had a chance to hit it hard yet.

    If anyone has any work-arounds to add/remove columns (maybe there's something obvious hidden in a context menu that I'm just missing?) I'd love to hear about it.


  • Linq to SQL with multiple databases

    I think I've mentioned that I'm working on a project that dips its fingers into databases all over the place. Its main goal is to eliminate all the systems we have around that are also doing this.  If it has to be done at all (and, really, it does), it should only happen once.

    One of the biggest issues I've run across while doing this is that Linq to SQL just does not play nice with multiple data contexts.

    If you're working with 3 different databases, that's 3 different connections.  Linq to SQL will not let you do any joining etc.

    You can't pull the results of one query into memory and then join against that (well, you can in some really isolated circumstances, but it's mostly a crap shoot).

    The only Linq to SQL solution I've found so far is to run a query on the first database, do a foreach over it, and query the second database multiple times.  This, of course, is usually brutally slow.

    I worked out a compromise with our DBA.  He added something he calls variously "data links" or "linked servers" or "server mappings" to the central database I need.  They now show up as read-only tables there.

    Performance is still spotty, and I'm not sure it's even vaguely something that could be considered a best practice.  I suspect it's some sort of gaping security risk.  But apparently that's the way they've been doing business for years: "Need data from our database?  Here, let me set up the views we'll let you see in your database."

    If I cared more about dba stuff, I'd look up what was actually done, give technical details and analysis, list pros and cons, etc.

    But, if your organization's anything like the one where I work, where security's a combination of swiss cheese and flaming hoops, you're trying to work with multiple teams who all have their own opinions and philosophies (and no one's willing to concede that they're all pretty much equally valid), and you're supporting a wide range of technologies, sometimes just finding a solution that works is enough. 


  • Some Initial Thoughts on Google App Engine

    More like observations, really. There's nothing here that's new or interesting, if you've been following it at all.  But, if you've been mildly curious and haven't taken the time to really read anything at all, this may be worth your time.

    I was really excited about the app engine beta.  But that's mainly because I like messing around with new tools and technologies.  And, unlike a lot of people I know, I consider it valuable to branch out into areas which most likely won't lead directly to a pay increase.  Call it personal development or stupid hippy nonsense, depending on your personal preference.

    Anyway, I've been playing around with the app engine for a couple of weeks now.  Nothing serious or meaningful; really just trying to get my head around some of the differences. So a little toy apps (I still think of them as homework assignments) here or there to try out some concept, trying to keep up with the mailing list, that sort of thing.

     Anyway, here are some random thoughts so far:

    Python's still an incredibly fun and easy language.  No, it isn't as powerful as ruby.  But it's so much more intuitive that it's just silly.  I thought I was just biased, but a couple of friends who have tried both agree.  For you die-hard .NET fans, I highly recommend checking out Iron Python.  Being able to open up an interactive interpreter and dink around with various classes is a great way to learn how to use those classes.  (Or, for that matter, just to observe what they're doing and why something breaks. It's a lot faster for me than using a debugger).

    App engine is still definitely in beta.  There are some huge bugs on the bug list.  But they're also cleaning bugs and adding features at an astonishing rate.

    Some of the basics they left out will be deal-breakers for a lot of people, if alternatives don't appear quickly.  One that I keep running across on the mailing list is the lack of XML support.  I'm really shocked this hasn't been fixed.  I think XML's way over-used, but it definitely feels an important niche.

    The data model seems to be a huge learning curve for anyone who's ever done any database design/theory.  For one thing, writes and joins seem to be ridiculously expensive. The "best practice" that I've seen most often seems to be "run one query, against one table, for each request.  At the most."  Since I tend to try to normalize everything, unless there's a reason not to, that's a little difficult to accept, deep-down.

    They aren't really targeting the enterprise. Which is kind of ironic, since one of the biggest saling points (in my mind) is scalability. I suspect they're getting a solid basis with individual developers.

    Have I mentioned the scalability?  What they've given independent developers just blows my mind.  You accept the limitations of their sandbox, and your app runs on their server cloud.  I can't think of anyone besides amazon who's even close to that league. And, with their EC2 offering, you have to waste time setting up and configuring the server.

    With google's offering, you run a little command-line app, it uploads, and possibly re-indexes (when that happens seems to be a little fuzzy, and it can be *brutally* I said, definitely beta) your database. You start getting tons of hits in Australia, they load your app onto servers down under and process requests there.

    Anyway, it's a nice change of pace from SQL and C#.


    Oh, yeah. The whole reason I started this post. With the latest SDK release, they've added a bunch of image processing functions.  These seem to be based on the Python Imaging Library, because the local server complained about that being missing when I started it the first time.  That was the only place I've seen this mentioned.  I'm familiar with it from way back, but I thought this little hint might help some of the newer people who seem to be drifting in from PHP. So, if you get that error and the Image API doesn't work, go to that link, install the library, restart the GAE server, and you should be good to go.


Powered by Community Server (Non-Commercial Edition), by Telligent Systems