.NET Megathread 3.5: await GetGoodPosts()

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›6 »

RICHUNCLEPENNYBAGS: Dec 21, 2010

Bognar posted:

I really like what async/await gives you, but I do agree that there are some nasty hidden gotchas. My main complaint is that you're not able to easily call an async method synchronously. Doing that is basically a recipe for deadlocks, but what option do I have if I'm not running in an async ready context (e.g. console app)? This forces most libraries to expose both synchronous and asynchronous method calls which just pollutes their APIs. If calling asynchronous methods synchronously was easy then we could get rid of this silly *Async duplicate method convention and just expose async methods.

What's wrong with Task.RunSynchronously or even just Result? Well, I mean, what's wrong that some other syntax would fix?

# ¿ Jun 21, 2014 07:28

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 12:12

RICHUNCLEPENNYBAGS: Dec 21, 2010

Ithaqua posted:

If you have async code and try to use it synchronously, Bad Things can happen in the form of deadlocks; the async code just waits for something that's never going to happen because everything else is held up waiting for the task to complete. Of course it all depends on the synchronization context... a console app will be fine because it has no synchronization context, it just passes it off to the task scheduler.

[edit]

Even though Stephen Cleary irks me on a personal level, he knows this poo poo inside and out and explains it really well:

http://msdn.microsoft.com/en-us/magazine/jj991977.aspx

Yeah, but I don't see an easy fix for that.

# ¿ Jun 21, 2014 08:05

RICHUNCLEPENNYBAGS: Dec 21, 2010

OK, I'm gonna go ahead and ask this dumb question: MVC seems to have an attribute you can put on actions where you can cache the page render, but how could caching the entire page be useful when you have a bar showing the username and so on? What I'd really like to do, of course, is cache portions of pages, and for certain circumstances (like caching one tenant's version of a page and serving it to everyone in a multi-tenant app is also bad). Is there like, an obvious built-in tool for that or should I be rolling my own?

# ¿ Jul 25, 2014 05:07

RICHUNCLEPENNYBAGS: Dec 21, 2010

I would swear there was an easy way to do this. Isn't there a way to go from a lambda to the full, written out expression (in other words, creating expressions by explicitly calling Expression.whatever)? Sometimes I feel like it would be helpful when trying to do things with expressions if I could just write out simple examples and look at the results.

# ¿ Jul 25, 2014 22:50

RICHUNCLEPENNYBAGS: Dec 21, 2010

Sedro posted:

It's an implicit conversion provided by the language. The compiler will generate the expression tree.
C# code:
Expression<Func<string, int>> expr = s => s.Length;

Yes, I know that. But that doesn't help me do things like visit expressions, modify them, etc. So what I would like to see is the equivalent, long-way-round code. I think maybe you can do this by compiling and then decompiling with the decompiler set to a lower version of .NET or something like that.

# ¿ Jul 26, 2014 02:26

RICHUNCLEPENNYBAGS: Dec 21, 2010

gently caress them posted:

Just what exactly are ALL of the places one can change how requests are returned in .NET? I've gone through every single decorator I can find for my methods in .svc and .asmx and .whatever files, and I want to return JSON, and I keep either returning a single XML string which itself contains JSON, or I return JSON in a SOAP envelope.

Is there something in web.config I've overlooked? I've scoured MDSN, stack overflow, google, and even tried restarting VS a few times, and it's getting very frustrating.

I just want to spit out a JSON string

Why can't you just return a JsonResult? Or use Content if it's already a JSON string?

Also you should probably be more specific about what you're trying to do since here I am giving you an MVC answer but you've not mentioned at all what kind of application it is so it may very well be irrelevant. Your question is kind of ill-formed ("anywhere" if you don't specify the library).

RICHUNCLEPENNYBAGS fucked around with this message at 06:00 on Jul 27, 2014

# ¿ Jul 27, 2014 05:57

RICHUNCLEPENNYBAGS: Dec 21, 2010

Dietrich posted:

You ever finish something really complex and want to throw up your hands and cackle "It's alive!!" the first time it runs?

No, not until it produces results that are close to what I intended.

RICHUNCLEPENNYBAGS fucked around with this message at 01:08 on Aug 3, 2014

# ¿ Jul 31, 2014 03:14

RICHUNCLEPENNYBAGS: Dec 21, 2010

Bognar posted:

We attempted to use it for a recent project, but ultimately we threw it out and rolled our own like we have done for years. I wish MS would get away from trying to provide the "one identity solution to rule them all" and instead just provide sane defaults for password hashing, password requirements, and default functionality for email validation, password resets, and the like.

V1 is missing some obvious stuff but they added it in in V2. I haven't switched my work project over because we did our own versions of password resets and e-mail validation and now changing them would be a hassle but they're there in V2.

Che Delilas posted:

I'm trying to learn MVC for a personal project and to expand my skillset in general, and this Identity poo poo is not making it easy, let me tell you.

What are you stuck on?

# ¿ Aug 4, 2014 12:46

RICHUNCLEPENNYBAGS: Dec 21, 2010

Che Delilas posted:

Customizing it to suit my project's needs. I don't understand how all the pieces fit together, and so I don't know what to modify/add to enable things like role-based authorization and administrator approval of new registrants.

I'm pretty sure it's a combination of information overload and inexperience with ASP.NET and web development in general. I'm not very familiar with what goes into authorization and authentication because all my previous experience in that area is "if they can install it with ClickOnce because they're in the right AD group, they're authorized to use it" corporate-style development. Trying to learn anything about it by examining Identity code is just confusing me.

Role-based authorization is just an attribute at either the controller or the action level like Authorize(Role = "Role1,Role2"). For provisioning, you can probably just use the UserManager class (I mean that's more complicated if you need to IMPLEMENT one, but not insurmountable). I've spent a fair amount of time with it and I'm sure other poeple here have too.

wwb posted:

In general my experience has been one is best left leaving the authentication bits as a functional black box and then keeping your app's data (like demographic / address info) in data stores tied to my app. We typically go so far as to keep that asp.net databases as a physically separate DB as we don't like schlepping user logins back to developers.

That said, the new extensibility points in the Identity bits should make extending stuff to use a custom user with this info is much easier than what one had to do with the old membership providers. But I still don't like mixing the two myself.

There's no reason at all to avoid adding fields to your ApplicationUser class/subclassing it/whatever. Especially if you're using the EF Code First Identity and EF Code First in your application. Nothing to it.

If it were me I'd make Address a class and give ApplicationUser an Address field.

RICHUNCLEPENNYBAGS fucked around with this message at 04:42 on Aug 5, 2014

# ¿ Aug 5, 2014 04:38

RICHUNCLEPENNYBAGS: Dec 21, 2010

edit: whoops, never mind.

# ¿ Aug 7, 2014 04:48

RICHUNCLEPENNYBAGS: Dec 21, 2010

comedyblissoption posted:

Does anyone have a recommendation for a resource for learning F# for someone pretty familiar with C#?

There are a couple books with that very premise.

# ¿ Aug 10, 2014 22:37

RICHUNCLEPENNYBAGS: Dec 21, 2010

Drastic Actions posted:

Avoid Winforms. Unless you have a reason to use it, don't. Not at this point. I would say it would not help much at all from a WPF angle, because they are different.

And you don't have to have a fully working project to throw it on Github, or at the very least put it under local source control. Just put what you have and do commits when you make changes. That way you can mark what you're doing and go back if you need to.

Winforms isn't that bad if you have some discipline but you end up having to work with other people who put all the calculations in the freaking code-behind.

# ¿ Aug 28, 2014 03:07

RICHUNCLEPENNYBAGS: Dec 21, 2010

Smugdog Millionaire posted:

How many of you guys use ILSpy? I started using it because it was easier than getting my employer to pay for Reflector licenses and I've always found the UI a bit clunky. I've started using some of my free time to fix issues that I personally have; does anybody else have any grievances that they'd like someone to look at?

dotPeek is available for free too.

# ¿ Aug 31, 2014 02:53

RICHUNCLEPENNYBAGS: Dec 21, 2010

spiderlemur posted:

Is there a good way to integrate certain CMS features into an existing site without having to full on use a CMS? I don't want the CMS taking over the site and disrupting what has already been written, I just need a small portion of that site to support say, creating and displaying articles, with the other site pages / part of the homepage undisturbed.

Are there libraries out there that make it easy to add these kinds of features into an existing site or is the best way just to write it all myself? I'm using MVC.

Well, depends what you want to do but maybe you can have the two products communicate with a plain old REST API.

# ¿ Sep 1, 2014 16:29

RICHUNCLEPENNYBAGS: Dec 21, 2010

chmods please posted:

I think it's possible to convert an existing MVC site into an Orchard module, maybe you could look into that?

Or if that's too complicated, why not just make parts of the site dynamically generated, and only provide editors for those specific parts?

If that's all you're looking at it's hard to see what the CMS is really giving you over throwing TinyMCE or something over a textbox.

# ¿ Sep 1, 2014 16:37

RICHUNCLEPENNYBAGS: Dec 21, 2010

EssOEss posted:

Right. The reason for this separate box is not to make life for you easy, it is to make life easy for the colleagues who have to work with your stuff.

Installing real IIS on your PC is just an answer to your question, it is not the solution to your problem.

So for people for do this how do you handle different branches working with modified database schemas?

# ¿ Sep 7, 2014 15:51

RICHUNCLEPENNYBAGS: Dec 21, 2010

gently caress them posted:

At home for lunch, so paraphrasing.

dim return = LinqToEntities (Or LinqToSql? It's old)

You're not sure which you're using? I'm not surprised that you're having problems.

# ¿ Sep 8, 2014 22:35

RICHUNCLEPENNYBAGS: Dec 21, 2010

darthbob88 posted:

This is probably a stupid question, but is there a good way to write data to multiple files simultaneously? I'm trying to create a system for cataloging my media collections, so that if I ever lose the files I can rebuild/replace them, and I'm putting the catalogs in cloud storage, so I can retrieve them even if my main computer dies. I'd like to be even more redundant, and store the files in multiple cloud storage folders, so even if Dropbox and Microsoft OneDrive fail, I can still get them from Google Drive. At the moment, I do that by writing the files to one folder and manually copying them to the other folders, but that's reliant on me remembering, and it'd be good if I could have the program do it automatically. I probably could also use File.Copy, but that seems inelegant, so I'd prefer to just have a StreamWriter that can write multiple streams at once, without too much juggling.

Sure, this kind of thing is easy with async methods, which StreamWriter exposes... just add a bunch of tasks to a list (or Select them or whatever) and use Task.WaitAll when you need to.

# ¿ Sep 11, 2014 02:46

RICHUNCLEPENNYBAGS: Dec 21, 2010

Bognar posted:

C# code:

public class MultiFileWriter
{
    public Task WriteFilesAsync(byte[] data, params string[] files)
    {
        var tasks = files.Select(f => WriteAsync(data, f));
        await Task.WhenAll(tasks);
    }

    private Task WriteAsync(byte[] data, string path)
    {
        using (var fs = new FileStream(path, FileMode.Create))
        {
            await fs.WriteAsync(data, 0, data.Length);
        }
    }
}

Bugs + typos may exist, code from the internet warnings still apply.

More or less what I had in mind, yeah. I like async/await a whole lot; I miss it when working in JS-land and having a million callbacks.

# ¿ Sep 12, 2014 05:06

RICHUNCLEPENNYBAGS: Dec 21, 2010

I'm using EF Code First with a DB my application owns (like there are no other clients and for various reasons I strongly doubt there will be any that don't use my data access library).

I'm running into efficiency problems because in some places I've declared navigation properties in derived types and if you're doing queries on the supertype, you can't use the Include method to include navigation properties that only exist on subtypes. So what happens instead is you fall back to lazy loading and the database is hit every time you hit one of those properties which can be quite a few queries. You can do an OfType<> query and concatenate things together but that's messy and doesn't work too well for a lot of scenarios.

I'm thinking about a couple ways I might ameliorate it, but I'm not entirely sure I'm happy with either. Is there a better way, or, if not, which of these seems better?

1. I could move the actual declaration to the base type, using some sort of naming convention to indicate that these are "private" (not really because they have to be public, but that they should be treated as private) (e.g., _Property instead of the usual Property). I could then, on the derived type, add in a "real" property and just have the getters and setters refer to the base property. I think if I do this right I can even avoid changing the DB schema. My biggest issue with this is it's going to introduce a lot of noisy boilerplate for classes with a lot of descendants.

2. I could switch to serialization, then hook into EF's materialization to deserialize, serializing again on the save event. This certainly makes it simpler (hey, don't need to include anything at all!) and I don't really need to do queries on the contents of the fields in question. But this does go against normal sound DB design so I still have misgivings (although to be fair it's not like my Code First-generated database schema is a paragon of good DB design either).

(There's obviously the option of ditching EF but at that point I'd sooner just live with the problem because it would be a ton of work)

# ¿ Sep 20, 2014 03:01

RICHUNCLEPENNYBAGS: Dec 21, 2010

EssOEss posted:

Can you lay out an example of the tables & entity classes you have and the queries you are attempting to run? The description is a bit hard to understand.

Imagine these classes:

code:

public abstract class BaseClass {}

public class DerivedClass : Baseclass
  {
    public virtual ICollection<ComplexObject> Collection {get;set;}
  }

Basically I want to do this

code:

context.BaseClasses.Where(bc => meetsSomeCondition(bc)).Include(bc => bc.Collection) 
// you can't actually do this

Yes, there is an overload that takes strings, but it doesn't work either.

So because of that I'd like to change things in such a way that an include is unnecessary to avoid another query.

# ¿ Sep 20, 2014 18:39

RICHUNCLEPENNYBAGS: Dec 21, 2010

Che Delilas posted:

Eager loading of derived types does not appear to be supported, nor are they even working on it.

http://data.uservoice.com/forums/72025-entity-framework-feature-suggestions/suggestions/1249289-include-property-of-derived-classes

I can't think of a solution that isn't a huge pain. Refactor your entity model so that it doesn't use inheritance (I know, this is also a huge pain)?

Did you see my previous post? I had two possible solutions in mind, one of which was sort of that.

# ¿ Sep 21, 2014 00:59

RICHUNCLEPENNYBAGS: Dec 21, 2010

EssOEss posted:

I tried using a subclassing structure for modeling my database once and I will never try it again. This is just one of the headaches you will encounter. My recommendation is to not try to make any fancy entity model - just treat your entity classes as database rows and you'll have a happy life.

I don't necessarily disagree with this but I'm on version 3 of this application and I'm not gonna change it now.

# ¿ Sep 21, 2014 17:34

RICHUNCLEPENNYBAGS: Dec 21, 2010

RangerAce posted:

Inheritance is usually bad and this is one of many reasons why. There are some scenarios where an open or quasi-open schema would work better than straight inheritance. Then, you expose your entities as views. The views give you a little bit more abstraction between your tables and your database code.

I don't really bother with EF (or most other ORM like it) anymore. I feel like EF is a trap that lulls you into using a bunch of weird inheritance, and you end up spending more time tweaking queries and includes than you would've just creating a set of repository classes that wrap SQL calls.

Inheritance is "usually bad?" Like, not just in ORMs but in general design? Seems like an overly reductive way of programming to me.

I don't agree on the ORM front. Sure, making it run efficiently takes some effort, but 1) it is very easy to get it running correctly, without worrying about performance at all (which can matter if you had to just get something out the door first) 2) tuning the performance is still much easier than writing all the SQL to do equivalent things for some of the more complex things you can ask for.

Besides that EF (or any provider that implements LINQ) lets you build up an expression dynamically (with the various classes that inherit Expression) and then use that same expression either on a database or on an expression that exists in-memory which is insanely cool and useful if you want to offer, say, a reporting function.

# ¿ Sep 24, 2014 02:55

RICHUNCLEPENNYBAGS: Dec 21, 2010

If it works for you I'm not going to knock it but some of the scorn directed at ORMs doesn't make a lot of sense to me. Like, yeah, they're slow, but "my application is so popular and otherwise performant that the speed of the ORM is a real issue" is like, a nice problem to have and one many of us don't.

# ¿ Sep 24, 2014 04:51

RICHUNCLEPENNYBAGS: Dec 21, 2010

OK, I'm feeling in a heretical mood, so I'm going to go ahead and bite on this: is it really morally superior to have a whole separate data layer that looks up an object by ID rather than to have context.SomeDbSet.Find(id)? What's it giving you?

# ¿ Sep 24, 2014 05:54

RICHUNCLEPENNYBAGS: Dec 21, 2010

Bognar posted:

Well, for one, it makes it much easier to unit test if you're calling an injected interface method that returns your data rather than calling a method on a concrete ORM DB object. Another benefit is that all of your queries live in one project, so if you have to refactor something in your data, you're not changing things over your entire solution. Also, if for some reason you need to drop down to SQL instead of using the ORM (e.g. for performance), you can do so in that one method without having to touch the calling code.

Why not just mock the repository itself? That's the approach I'm using... an IRepository class that's a very thin layer over DbContext so I can switch it out in tests.

That doesn't answer the other benefits you have mentioned though, and certainly the Include thing is good too (although the problem is what needs to be included is kind of consumer-specific).

RICHUNCLEPENNYBAGS fucked around with this message at 14:11 on Sep 25, 2014

# ¿ Sep 25, 2014 14:09

RICHUNCLEPENNYBAGS: Dec 21, 2010

I suppose that's reasonable although the price you pay is more code upfront.

# ¿ Sep 25, 2014 15:47

RICHUNCLEPENNYBAGS: Dec 21, 2010

Newf posted:

Here's a question to slot into inheritance/EF chat.

I've been working on something with MVC but I'm starting to doubt whether it's the tool for the job. The short of it is that I've got some slowly growing (as the system matures) number of hand-made classes each of which have ~100 instances stored in the DB. Each class also has associated with it at least one but potentially any number of views. My first look tells me that it's going to be a pain to store the views themselves in the DB, since the framework wants to be loading them from Views/ClassName/ActionName (or whatever, but it wants to be loading physical .cshtml files).

In practice, I expect classes to be static, but the views (including the number of them assigned to each class) will be in flux in a partially automated, partially user driver way. Moreover, the system itself needs to be 'aware' of the coming and going of the views. This is why I prefer to have them persisted as DB objects rather than as physical files.

Does anyone have experience with VirtualPathProvider to do this sort of thing? And on a related note, how inconvenient would it become to be editing razor views in VS in order to then persist them to the DB? Probably just a matter of setting up an alternate project to store all of that?

This is total greenfield and it's my first time looking at MVC, so it's possible that I'm missing a better route to take with MVC, and it's also possible for me to ditch and move to another framework if something is a more natural fit with my intention.

Would appreciate any feedback.

You're not supposed to be storing view models in the database, which I think is probably the root of your problem. Store one representation and map it into your view models at runtime.

As far as inheritance, sure, very deep hierarchies can be bad, but I think it's insanely reductive and silly (and going against the principles of framework code and so on) to say inheritance should just be avoided altogether.

# ¿ Sep 26, 2014 00:45

RICHUNCLEPENNYBAGS: Dec 21, 2010

epalm posted:

If my test project does a pretty good job of testing my services and visiting most code paths, but uses a database instead of mocking out repositories, does that make me a bad person?

For things that must be unique, like product names for example, I have to do stuff like product.Name = Util.RandomString(length: 20);

But the idea of creating like 40 mock repositories just sounds like a monumental amount of work.

This is the problem generics are meant to solve, isn't it? I have IRepository<T> and then I use Autofixture to spit out objects. But I mean, hey, if it's working for you and the drawbacks aren't giving you trouble then no worries.

# ¿ Sep 26, 2014 03:01

RICHUNCLEPENNYBAGS: Dec 21, 2010

Ithaqua posted:

Yeah, there's no excuse to not mock your repositories assuming you're already coding to an interface. VS2012 and beyond even includes a lightweight stubbing framework built-in, if you don't want to use something like Moq.

Pretty big assumption if you ever look at the applications people churn out.

# ¿ Sep 26, 2014 16:27

RICHUNCLEPENNYBAGS: Dec 21, 2010

Che Delilas posted:

The more you use EF, the more you will look into something and find that the answer is, "EF can't do that right now" or "This is a bug in EF," usually accompanied by "We have no plans to work on this issue." What fun!

The lovely handling of Include with subtypes really cheeses me off but everything else I've eventually found a workaround I was satisfied with for.

# ¿ Oct 4, 2014 05:14

RICHUNCLEPENNYBAGS: Dec 21, 2010

Bognar posted:

The problem is that the user manager has its own DbContext and you are trying to add an item from that context onto the new one that you're creating. Using the Id instead is a good way of doing it, but you need to make sure you still have a foreign key set up. This model should tell EF Code First to make AddedByUserId the foreign key for the AddedByUser relationship.
C# code:
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public ApplicationUser AddedByUser { get; set; }
    public int AddedByUserId { get; set; }
}

In my opinion "one context per request" is the most sensible way to use EF. Just share the context with the UserManager.

Bognar posted:

This is a question that I've had for a while, but haven't delved into deeply enough to figure out it. If anyone here has some insight before I do, that would be great.

Does Entity Framework Code First with migrations support interacting with a database if the database has *newer* migrations?

EF rightfully explodes if the database it's talking to doesn't have the latest migration. However, there are situations where I would still want EF to continue to interact with the database even if the database has been updated to newer migrations.

For example, I might have a web site running 5 replicated web servers. I want to add a feature that requires adding a table to the database, and I want to update the web servers without a gap in uptime. Without EF, I can modify the database, and update the web servers one by one. However, with EF and migrations, the web servers with old code might blow up when trying to talk to a newer DB.

Most of the sites I've worked on have had one web server that got updated when the DB updated, and for 15 minutes we just told the users to hold on. I want to break that model, but I'm worried that I can't do it with EF.

EDIT: Okay nevermind, we just tested it with one of our staging sites and it seems to work great.

Sure. You can also ask it to ignore missing migrations with one of the options or you could trick it by doing an empty migration.

# ¿ Oct 7, 2014 23:21

RICHUNCLEPENNYBAGS: Dec 21, 2010

gariig posted:

How would a fake DbContext know that your relationship should fail? It's just going to let your code call into it, return pre-recorded behavior (Setup/Returns), and to allow you to Verify calls. If you want to test what happens when your code gives a bad relation you can have Moq throw an exception.

What you want is an integration test where you aren't mocking your DbContext but using a MyContext against a real database.

The Art of Unit Testing is a great book that goes over unit testing and touches on integration testing.

Do you? Frankly I think a mocked out DbContext is pretty useful in a lot of cases and with the integration test you run into consistency problems.

# ¿ Oct 8, 2014 03:18

RICHUNCLEPENNYBAGS: Dec 21, 2010

I'm using EF and I'm wondering how to cope with performance issues that stem from having to do too many joins (basically the model looks great from a C# perspective but wasn't made with much thought to the underlying DB structure -- tight deadlines). I've given this some thought and one thing that I did think of is that I'm using a lot of entities as essentially immutable objects due to other design goals -- information is generally only ever added, rather than modifying old records. I think I might be able to make some performance gains by loading up entities into a cache (Redis? Just memory? I don't know) and using that instead.

If I pursue this what I wonder about is when to cache the data. The problem is that you end up having to descend a lot of the object graph so that the cached item is useful in a broad number of scenarios which is probably slow. Separate service? Dynamic proxies that go to the database and get new properties and update the cache (basically copying EF's lazy-loading strategy)?

Surely someone here has implemented something like this.

# ¿ Oct 10, 2014 02:53

RICHUNCLEPENNYBAGS: Dec 21, 2010

RICHUNCLEPENNYBAGS posted:

I'm using EF Code First with a DB my application owns (like there are no other clients and for various reasons I strongly doubt there will be any that don't use my data access library).

I'm running into efficiency problems because in some places I've declared navigation properties in derived types and if you're doing queries on the supertype, you can't use the Include method to include navigation properties that only exist on subtypes. So what happens instead is you fall back to lazy loading and the database is hit every time you hit one of those properties which can be quite a few queries. You can do an OfType<> query and concatenate things together but that's messy and doesn't work too well for a lot of scenarios.

I'm thinking about a couple ways I might ameliorate it, but I'm not entirely sure I'm happy with either. Is there a better way, or, if not, which of these seems better?

1. I could move the actual declaration to the base type, using some sort of naming convention to indicate that these are "private" (not really because they have to be public, but that they should be treated as private) (e.g., _Property instead of the usual Property). I could then, on the derived type, add in a "real" property and just have the getters and setters refer to the base property. I think if I do this right I can even avoid changing the DB schema. My biggest issue with this is it's going to introduce a lot of noisy boilerplate for classes with a lot of descendants.

2. I could switch to serialization, then hook into EF's materialization to deserialize, serializing again on the save event. This certainly makes it simpler (hey, don't need to include anything at all!) and I don't really need to do queries on the contents of the fields in question. But this does go against normal sound DB design so I still have misgivings (although to be fair it's not like my Code First-generated database schema is a paragon of good DB design either).

(There's obviously the option of ditching EF but at that point I'd sooner just live with the problem because it would be a ton of work)

To keep everyone out of suspense, I ended up moving the declarations onto the base class with properties named with a special convention, then putting a "normal" unmapped property that just wrapped them on the derived types. Didn't need to change anything about the database. It works well enough.

Now my next problem is to figure out why EF is inserting, unbidden, ORDER BY statements into huge queries which cause them to time out

# ¿ Oct 11, 2014 02:43

RICHUNCLEPENNYBAGS: Dec 21, 2010

Bognar posted:

Where is it putting the order by in the query and what does the query look like in code? I've never run into an ORDER BY statement being generated if not asked for.

At the end it has an ORDER BY with every single table it queried. I don't have the code in front of me, but it's just something like .Where(o => o.field == input).Include(o => o.NavigationProperty1).Include(o => o.NavigationProperty2).Single().

# ¿ Oct 12, 2014 06:30

RICHUNCLEPENNYBAGS: Dec 21, 2010

Bognar posted:

This could be an "optimization" applied for .Single(), since it has to check for duplicates. Try changing it to .First().

Yeah, I did try that, and FirstOrDefault, but it did the same thing.

Anyway I tried taking out the ORDER BY clause and running the query on my own and it was still unacceptably slow (I canceled it after it ran for 20-something minutes) so obviously I need a different strategy (or to just leave the lazy loading alone for now).

# ¿ Oct 15, 2014 00:32

RICHUNCLEPENNYBAGS: Dec 21, 2010

Bognar posted:

I don't know what your database looks like, but it's likely that you could benefit from some proper indexing. Also, what's this about lazy loading? Never lazy load, it's terrible.

Yeah, it bad and the performance is bad, but on the other hand, until I can invest some time in really fixing the database (either through fixing the indices or denormalizing or something else) I have the choice between lazy loads doing extra queries and taking like 20 seconds to load a page, or trying to include everything except it takes more than 30 minutes so it times out and you can't use the page at all. I can't really fit a proper fix into the release schedule for this version; it's gonna have to go into the next one.

My project is in the process of maturing from a quick hack job with a very aggressive deadline on an unfamiliar technology stack to a more mature thing so I'm kind of working to clean up a lot of poor practices with Entity Framework in particular now.

RICHUNCLEPENNYBAGS fucked around with this message at 00:53 on Oct 16, 2014

# ¿ Oct 16, 2014 00:49

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 12:12

RICHUNCLEPENNYBAGS: Dec 21, 2010

Alien Arcana posted:

EDIT: Oh, I can use dynamic! Nothing could possibly go wrong with that!

If you're doing dynamic stuff it'll come out way better to use dynamics than to gently caress around with scores of lines of reflection for each member call.

That said, in your case you probably want to check typeof(IEnumerable).IsAssignableFrom on the properties and iterate over them if so. I mean, you're doing graph traversal to serialize this thing, right?

# ¿ Oct 29, 2014 00:09

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›6 »