Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
JawKnee
Mar 24, 2007





You'll take the ride to leave this town along that yellow line
When dealing with the <defaultProxy> element, does useDefaultCredentials refer to this property?

Adbot
ADBOT LOVES YOU

JawKnee
Mar 24, 2007





You'll take the ride to leave this town along that yellow line
That... is not what I was expecting, but thank you for the very helpful answer!

JawKnee
Mar 24, 2007





You'll take the ride to leave this town along that yellow line
My work also uses serilog and it's great. You can pair it with something like Seq, or have it write to whatever else

JawKnee
Mar 24, 2007





You'll take the ride to leave this town along that yellow line
I am currently having to interact with an Active Directory server via LDAP, using LdapConnection; part of what I need to do involves retrieving user properties (e.g. the `memberOf` attribute). This, and other properties, are returning as an array of ascii values; I would like them to be in a more human readable form (e.g. like what ldp.exe returns). I think that ldp is just doing some intelligent decoding behind the scenes, and I'm wondering if LdapConnection has the same capabilities via some configuration option I'm just missing.

Failing that, is there a way of determining ahead of time what attributes are going to be returned as ascii? I realize this might not be the best place for this question, so if there's somewhere else I should ask I'd love to hear about it

JawKnee
Mar 24, 2007





You'll take the ride to leave this town along that yellow line
I have an EntityFramework question, specifically EF6. In a project with a model generated using code first, which is also using (and will continue to use) code first migrations, is there a simple way to add a entity class (and DbSet) for what is currently an existing join table in the database without having to rename/migrate/drop the existing table?

When adding the class and DbSet, EF considers this a model change and as a result requires a migration. I can add an empty migration with -IgnoreChanges, but this still results in problems with the generated model in the migration history (namely you'll end up with a renamed table there, if not in your database). Looking at the current model builder during `OnModelCreating` only shows the newly added explicit class, so if I can catch this there, I'm uncertain how.

As a more concrete example drawing from the EF documentation, let's say I start with the following entities:

code:

[Table("Tags")]
public class Tag
{
	[Key]
	public int ID { get; set; }

	[InverseProperty(nameof(Post.Tags))]
	public virtual IList<Post> Posts { get; set; } = new List<Post>();
}

[Table("Posts")]
public class Post
{
	[Key]
	public int ID { get; set; }

	[InverseProperty(nameof(Tag.Posts))]
	public virtual IList<Tag> Tags { get; set; } = new List<Tag>();
}

And I want to add the existing join table, PostTags, that was created in some long ago migration as an explicit DbSet/entity class like so:

code:

[Table("PostTags")]
public class PostTag 
{
	<pretend I put all the various bits in here, composite primary key, foreign keys, indexes and such>
}

How do I do so without ending up with a phantom PostTag1 in the model? I can create a migration that renames the existing table, adds a new one, migrates data, and drops the existing table, but I would like to avoid that if there's an easy way to do so

JawKnee
Mar 24, 2007





You'll take the ride to leave this town along that yellow line

biznatchio posted:

If I'm understanding your problem right, all you need to do is to add to your DbContext's OnModelCreating:

code:
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<PostTag>().ToTable("PostTags", t => t.ExcludeFromMigrations());
}
You may still need to create a new migration; but nothing should be done to the table in the migration. Depending on your use case though, you may want to manually add code to the migration's Up method to check to see if the table exists and create it if not -- otherwise if you ever need to recreate a database from scratch via migrations, that table will not be present.

(Also I'd have to check to be sure but I'm fairly certain that after you've captured the model in a migration with the table present and marked as excluded, you can then remove the ExcludeFromMigrations configuration and for future migrations the table will be assumed to already be present, and then you can have EFCore maintain any future changes made to it via migrations. But I'm not sure I've ever actually done that myself so you'll want to verify that behavior.)

Appreciate the response - just haven't had the chance to try out the above - will update when I have. I also think there might be a few issues with the particular situation I find myself in here that might make it a bit more complicated (regularly creating new databases with the same set of migrations applied). We're also not using EFCore, but that's a problem for another day.

Adbot
ADBOT LOVES YOU

JawKnee
Mar 24, 2007





You'll take the ride to leave this town along that yellow line

biznatchio posted:

Oh my bad I totally missed that you said EF6. That approach won't work in EF6.

For EF6, I believe you can just generate the migration class; then go in and manually edit the generated code's Up method to add an appropriate check query to replace the generated CreateTable method (using the Sql method to query the database's schema tables) to see if the table actually needs to be created. Then once that migration exists, later generated migrations should presume the table already exists.

Something like this:

code:
public partial class MaybeCreatePostTags : DbMigration
{
    public override void Up()
    {
        Sql("if not exists (select 1 from information_schema.tables " +
            "where table_name = 'PostTags') create table posttags (....)");
        // removed generated code:
        // CreateTable("PostTags", ...);
    }

    public override void Down()
    {
        // probably don't want to remove the table on down, so comment out the
        // generated drop table call
        // DropTable("PostTags");
    }
}

Yeah this is unfortunately subject to the same issue as just setting `IgnoreChanges`. A table isn't created in the DB schema (good), but the generated .resx contains references to both the desired table (PostTags) and the undesired one (PostTag1)

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply