adamfoneil / modelsync Goto Github PK

I want to avoid this message. Incompatible types shouldn't block the whole app

It's too unpredictable to load assemblies with LoadFrom or Load. There's just no simple way to ensure dependencies are present, and the mechanism for examining dependencies dynamically -- the AssemblyResolve event or whatever it is -- is just not straightforward enough.

The problem of course with "reflection only" assembly load is that attributes aren't supported in the usual way. Attribute info is available, but through some kind of abstraction that's very unlike ordinary attribute access I've done in the past. So, I think this can be done, but I'm really annoyed that I have to do this.

column alters should not have identity modifier

workaround is to drop the calculated column temporarily, then re-create after this alter completes.

In this query

SELECT
	[ck].[definition] AS [Whatever],
	[ck].[parent_object_id] AS [ObjectId],					
	[ck].[name] AS [Name]					
FROM
	[sys].[check_constraints] [ck]
WHERE
	[ck].[type]='C'

Dapper is refusing to map the definition column. I have no idea why, and I tried many different things -- aliasing it with a weird name and applying a CAST and TRIM functions to it. I tried concatenating dummy values on it. Dapper will not map it. I tried creating a new result class from scratch, and it still won't map it.

Adding a [Key] column to a model should result in PK change on table, but it didn't

Just noticed that they appear in the defined order within class

This will be the test case for #29. The idea here is to port the existing AssemblyModelBuilder to a more abstract, pluggable way of doing this so that different conventions may be swapped in and out.

I just wanted to document something odd that had stumped me for a couple days. In my test project I have a helper method ModelBuilder.BuildModel that lets me shorthand a data model for testing purposes. The problem I had was that FK json serialization was generating new tables in the Parent and ReferencedTable properties rather than reference the existing tables in the model. I had serialization code that worked as expected within AssemblyModelBuilder.ForeignKeyFromProperty, but I couldn't tell why it worked and my helper method didn't. It turned out the key difference was using ToArray on the DataModel.Tables property before resolving foreign keys.

I think the reason this worked is that ToArray ensures that the enumerable is "finalized." Without ToArray, the enumerable is executed anew with every foreach loop, so it looks like the objects within it are new.

currently only NET Standard 2.0 is supported, but we need to target different .NET versions (Core 3.x+ and Framework 4.7+). The exact versions are negotiable. A few things we need here:

• support Core 3.1+ assemblies
• support .NET Framework assemblies
• Integration test: Core test assembly (as embedded resource) demonstrating all attributes (Key, UniqueConstraint, Column, etc)
• Integration test: Framework test assembly (as embedded resource), same as above

Please use branch feature/multi-targeting

Developers have conflicting and strongly held beliefs about C#-to-SQL conventions -- for example what the [Key] and [ForeignKey] attributes represent exactly, and so on. Not to mention special attributes like my own [References] attribute in AO.Models. In ModelSync, the [Key] attribute is handled in a very specific way, resolving to one of several key configurations (primary, unique constraint, identity). Some devs want Guid keys, for example, some want int or long or string. Some devs want implicitly pluralized table names. (I don't.) The point is, it's very difficult to get agreement on universal database conventions.

The goal for this issue is to create an IAssemblySource that works with assemblies intended for Entity Framework EFModelBuilder

This will sit alongside the AOModelBuilder.

The EF version should accomplish much the same thing as the AO version, but should not reference AO.Models.

I had this before in earlier versions in the form of a validation "error" -- you had to add a DefaultValue attribute to the property if I recall, but I'd like to be able to supply a default through the ModelSync UI instead of requiring a code change. Because you have to simply remove the attribute after merging the change.

should not happen, probably result of changes a few minutes ago related to filtering single-line comments

Current functionality is aimed at syncing C# models to databases, meaning it covers things that have C# representations.
The point of this issue is to close some feature gaps when migrating databases, namely adding support for database-specific objects:

• #17
• #18
• #19
• #20
• #21
• #22
• triggers

Work is sort of in progress on db-to-db-improvements branch.

saw this message, and it shouldn't happen

I think I'd like to make a lightweight console app in order to get around the bad install/deployment experience I'm having with the WinForms app. The WF app has some legacy dependencies, gatekeeping components, and other complications that keep it from being easily used by others. A console app would be entirely free.

The main usability issue I foresee however is difficulty excluding objects. Often you aren't migrating every single diff. There would need to be a good way to exclude things and persist your exclusions, just like the WF app.

I need to add AspNetUsers.UserId, but I'm getting all these unexpected alters along with it. I'm expecting to see

ALTER TABLE [dbo].[AspNetUsers] ADD CONSTRAINT [U_AspNetUsers_UserId] UNIQUE ([UserId])

should not see [NotMapped] property in script

Because it's table AspNetUsers I wonder if it's being filtered out of SQL Server inspection

I had a class that resolved to table dbo.Item from two distinct C# classes, and it led to unhandled exception here I think.

The tables were separated by namespace, but this didn't separate them by resolved table name.

Type load exceptions have been an annoyance for a while now. Would love it if I could handle these by providing solution-specific paths.

To enable some improvements in the UI project, including a WPF implementation and a more marketable application overall, I see that we need to focus some efforts in this repo.

Please use the feature/architecture-improvements branch for all work on this issue.

• #34 (Usman)
• #29 (Prabhu)
• #16

Currently, a renamed table or column would be treated as separate drops and creates. I'd like to have explicit support for renames. I used to have a Rename attribute in Postulate that sort of handled this, but I haven't had that in a long time.

Sometimes it's not possible to load an assembly with reflection due to limitations and fine print about how .NET loads assemblies dynamically. As a workaround for these limitations, I suggest enabling projects to output their own data model info on startup using Assembly.GetExecutingAssembly as the basis. This requires users to add some special startup code to their application that will output a library's data model as json to the app's bin directory. ModelSync will then be able to load that json and bypass reflection limitations.