That would just be really cool and would help me out tremendously in my framework.

I assume for calculated fields, it would just return null for whatever the source was.

If not, is there any place for me to specify manually what the source table and field is? And also tell the view what the primary source table is?

I don't like the idea of creating relationships on view entities (what we primaryly use in our viewmodels) so that our framework can know how to auto map and auto populate values.

Sometimes we might use a table entity->table entity, table->view entity, or view->view entity, so I feel like I have to create lots of redundant relationships everywhere.

Ideally, if something is viewbased, it would be nice to know what the tables are behind the view, if there's a primary table backing that view and so that I can create all the relationships at the table level.

happyfirst wrote:

If not, is there any place for me to specify manually what the source table and field is? And also tell the view what the primary source table is?

So you want to know the source table and column behind a view field. That's sort of complex I think. A view column could be very complex, reference other views, expressions, subqueries, etc. And How do you know if the source is/n't a table? Doing manually? could be. With the LLBLGen Setting system you can create your own settings per element type, so you can create a setting called 'PrimarySourceTable' for TypedView element and another called 'SourceTable' for TypedViewField. Then you can fill those settings in your TypedViews at LLBLGen Designer. For more info read Defining and consuming Custom Settings.

happyfirst wrote:

I don't like the idea of creating relationships on view entities (what we primaryly use in our viewmodels) so that our framework can know how to auto map and auto populate values.

I see. So you want to know in advance what table is the target for some typeView field so you can, for instance, show a DropDownList to fill that. I see your point, but this is something that won't change much over time. So if a typedView field's source is TableX, it will typically be filled with TableX values, so you don't gain much doing this automatically, IMHO. But again, you can achieve that with custom settings as I said above

I agree this would be a complex feature to parse a view sql statement and determine what are the true sources. And sure, some columns would have no source. And if one column's source is really another view, then should that be the source or should it resolve it one step further and try to find the table?

I've seen the custom settings feature. But is there a way to get that to pop up a dialog to help me browse to another entity and it's fields. It would be a lot of work to do that way. If one could specify a primary source table and addl tables and then have a quick dialog of just those fields, a mapping tool would be really neat to be able to create those source relations quickly.

I guess I don't need every single field mapped to a source. Just the primary and foreign key ones. Anything that might involve a relationship.

It would just be really nice to be able to define a relationship in llbl at the table level, but then still be able to figure out what the relationships are if I'm coming from a view instead.

And like you said, if I configure my table entity with a custom setting for say a dropdown, it would be nice not to have to go repeat that setting in any related views.

I think you'd better map views into entities, and set relationships with entities(tables) having the PK side.

Otherwise if your views are simple and only joining entities, you can think of using TypedLists and drop the views altogether. TyoedLists are sompsed of Fields from already mapped entities.

But the view in the database has triggers we are relying on.

Then mapping to entities with relations set to other entities seems like the best approach.

happyfirst wrote:

I've seen the custom settings feature. But is there a way to get that to pop up a dialog to help me browse to another entity and it's fields. It would be a lot of work to do that way. If one could specify a primary source table and addl tables and then have a quick dialog of just those fields, a mapping tool would be really neat to be able to create those source relations quickly.

Have you seen the 'Bulk element setting manipulator'? This is in the v3.5 (now in beta), you go through Project->Bulk element setting manipulator. I think this could help you on this. If there is nothing like that you always coud write your own plugin for that