I have a batch file and I am trying to have llbl auto map and generate my db as 1to1 as possible from the command line.

It's mostly working but I still constantly deal with columns that initially are nullable, but then we make them not null in the db, but llbl doesn't auto change it's setting and so I have lots of warnings I'm always having to manually fix up.

Am i missing some setting that will take care of this for me? I'd like the catalog refresh to just auto correct those flags to match the database.

I wonder what setting do you have for the project property: "Reflect nullability of element field in target field" ?

So I've found that setting in the File|Preferences and I had it unchecked. I have checked off and refreshed my catalog. I still have all the same warnings. Should it have fixed them?

I notice that the table entities don't have warnings and it seems those are in sync with the db. The warnings are all in my views.

I did recompile my views and sql SMS is correctly showing me that the view columns are not nullable. It seems like LLBL also sees it from the view but doesn't update the view based entitity.

Ah, you are talking about views (entity mapped on to a view), the database view's metadata misses the information whether this field is nullable or not in the underlying table. That depends on your DB, but LLBGen just uses what it sees in DB's metadata.

The setting "Reflect nullability of element field in target field" is for model first, as it syncs target fields (relational model data) with the data in the model field (entity field).

So that's not going to have any effect here.

We only sync the entity field's IsOptional flag with the target if the value for the flag was the same as the target's before the refresh and only if the target is a table.

The reason is: if the value differs, the user must have changed it manually (otherwise IsOptional for the entity field would be the same as IsNullable in the mapped target field) and we can't reset user modifications as that would be a true pain. We also don't sync IsOptional for view targets as often these are reported wrong by the DB: for views, the meta-data for nullability for view fields is simply unreliable so we assume it's a matter of setting that in the designer anyway if you want to have good coverage of that. Keeping that in sync with the view in the DB isn't really helpful, as often meta-data for views is outdated: when a table's meta-data changes and it's used in a view, the view's meta-data stays the same till the view is dropped + recreated.

That's also why it's a warning and not an error.

Now, to the heart of the matter . I presume you're using the CLI refresher? The warnings after validation, they still stop the refresher from proceeding? As warnings shouldn't stop the refresher, only errors.

The CLI refresher works and doesn't stop on the warnings, but the real problem is the generated code isn't what I want.

I had a table and a view based off that table. I'm writing C# code and I come to a property that's nullable. It shouldn't be so I went into the database, ran a query to assign a default value, fixed the table so it wouldn't be nullable and recompiled the view and SMS correctly shows me that column is no longer nullable. I ran my batch file but in C# that view property was still nullable. I open the LLBL designer and I see a ton of warnings for all the other columns I've fixed and no longer allow nulls.

In my case, the value differs but not because I changed it in llbl, but because it changed in the db. I understand that a lot of views end up being wrong because developers don't go back and recompile their views after changing a table (I'm one of them that learned that a while ago), and so I've gone out of my way to make sure everything gets recompiled. Now I feel like I'm being penalized because the system is trying to leave things alone for those developers that don't keep their views in sync.

I need these C# properties to not be nullable. Now I have to manually go through and fix them all or just delete all my views and let it recreate them.

It would be nice if there was a setting to get the refresher to also update views so that those developers that are being careful to make sure their views are in sync don't have to keep fixing things in llbl.

What I want is to take EVERYTHING from the database ALWAYS. If it's something that comes out of the database, overwrite anything in llbl to whatever the db is. If it's something that only exists in llbl (like the identity columns on a view), then try and keep those.

You generate the db from LLBLGen, right? So why do you update the columns in the database not in the Designer, and regenerate the db ddl from there as well.

Also the thing about Views is not related to developers maintaining their views, we found out that metada that comes from the database is not always reliable.

I am database first and at least in my experience so far what's coming out of sql server is reliable.

If it wasn't then I wouldn't be getting all these warnings. Recompiling the views gets sql server to see they are not nullable and llbl is detecting that. It's just not updating the view entities.

The current code is this way since a fix in 2010 (v3.1). It depends on the philosophy that view nullability meta-data is unreliable and we can't sync that properly anyway.

Looking at the code, it indeed doesn't make much sense to have it only for tables and not for views as meta-data can be reliable. There's a caveat though:

we only sync nullability if entity field isOptional == old view's target field's nullable. If the values differ, we consider that a manual change (otherwise they'd have been the same) and manual changes won't be overwritten, not for tables and not for views.

So in your situation, after this change, you still have to drop/recreate the entities once. The values are then equal, and subsequential refreshes will be syncing the nullability.

That's the good news.

The bad news is that for v5 we have discontinued the cli refresher as the sync system has changed completely. For the future it might be it will come back but for now it won't be part of v5.0, so you have to use the designer for the refresh.

We'll make the change in the next build for v4.2, we can't see a breaking change in this, as it only has effect when the meta-data changes, and the user has to take action on that if that makes a difference anyway.

I'm confused as to why I would still have to drop the view, because then I loose the identity columns I had set for the view.

I found a table where the columns had an incorrect datatype. I switched the int to smallint and I refreshed. That change did correctly make it into my llbl view entity.

I am not making any manual changes in the llbl designer except for setting identity columns on view entities.

Why is it able to keep the datatype in sync but not the nullability?

How about a setting that just says take everything possible from the db always?

happyfirst wrote:

I'm confused as to why I would still have to drop the view, because then I loose the identity columns I had set for the view.

As I explained, you have to do this once, for the current situation where IsOptional != Nullable, as that's seen as 'has been modified by user', so it's not synced. It's also OK if the entity fields have their IsOptional value equal to the view field's Nullable flag.

I found a table where the columns had an incorrect datatype. I switched the int to smallint and I refreshed. That change did correctly make it into my llbl view entity.

I am not making any manual changes in the llbl designer except for setting identity columns on view entities.

Why is it able to keep the datatype in sync but not the nullability?

As syncing the datatype is something you always want. Nullability isn't always synced as there are situations where it's not always possible (subtype in TPEH) or wanted (nullable in view due to bad metadata).

How about a setting that just says take everything possible from the db always?

that comes down to restarting a project every time. the thing is that the designer migrates what's there and that has consequences: you can't always follow the DB.

But it's not as bad as you might think: once the entity fields have their IsOptional flag set equal to the view field's Nullable values, sync will happen automatically from then on.

Ok, I think I understand now. While I haven't made any manual changes in the sense that I want something different from the db, me fixing these nullability/optional warnings to get things in sync are considered manual changes.

In the next 4x version, after your fix, I'll need to drop the view, readd, reset my identities, but then I should no longer have any more warnings and those views will track the db.

Thanks!

Correct. You can also manually correct the IsOptional flags now, I don't know how much fields we're talking about, might be less work than recreating the entities.