It's not a flaw, it IS a feature . But indeed it IS also an aspect of using inheritance when mapping entity types on entities in the database. It's how inheritance is mapped onto table structures (you can do that in two ways, which are both explained in the concepts documentation. ) And these are the standard ways of how inheritance types are constructed in table structures. See for example Conceptual Schema and Relational Database Design (G. Nijssen / T. Halpin)

Inheritance of entities which are stored in one table per subtype, means that an entity's DATA is spread across multiple tables, when it's a subtype. This THUS means that a record in the table 'Object' CAN be just a PART of an entity's data! For example a User entity's data can be spread across 2 tables, Object and User. When you do select * from Object, you don't get all 'Object' entities, you also get the data of some User entities and perhaps other entities which are a subtype of Object.

If you don't want that, why did you make User a subtype of Object? You don't have to use inheritance You can also use the 1:1 relations, e.g. Object 1:1 User.

One man's feature is another man's flaw

See for example Conceptual Schema and Relational Database Design (G. Nijssen / T. Halpin)

Well I don't agree with everything this particular book says. But I understand what you are saying. Why have inhertiance if the supertype cannot be used seperately in other tables not joined the that particaulr subtype. I have been successfully doing it this way for years and it makes my life alot easier. Every invoice, user, customer, etc has a record in Object table.

That then brings me to where I am. So I can live with not pulling up the supertype in an entity collection if there are more then one subtype's of it. BTW why do you allow it in the designer then? Anyway, I am probably going to using another method anyway to grab lists of data and I want to be able to use LLBL to edit save individual objects.

With that said, under my current scenario. I have object records that belong to many different 1:1 entities that I would like to inherit, because it's easy to pull up one object that has all the necessary fields. Can I say that as long I don’t try to fetch and entity collection that has multiple subtypes, I wont have any other problems.

Inherited. Object <- User <- ManagerUser Object <- Application

Can I use the ManagerUser object fill it and save it without any problems or am going to have to disconnect this for the inheritance? I am ok without being able to have a list of ObjectEntityCollection filled on a webpage. Nice that it works on the winform. But again, if I add a record in ManagerUser I should get 1 record in each Manageruser User and Object tables. If I pull one up it will pull up that 1 record and modify that one record for each and not error out.

I could live with that. Other than that I would just generated one Entity per table and that is no fun and would the really necessitate something completely different. I would really like to use the inheritance feature.

Bryan

Otis,

Thanks for you help on this issue.

I have been thinking some more. It's just that I can't figure it out.

Why would you need inheritance at all in LLBL?

I mean if I can’t reuse the data structure of the supertype in another subtype, why does it at all. I am just confused as to when you are going to suggest using this. Why not just create the one table instead of inheriting from another table, if that supertype cannot be used in another subtype.

Confused?

Sorry for the endless sea of questions. I am truly trying to use your software to increase my productivity.

Bryan

BringerOD wrote:

One man's feature is another man's flaw

In this case I disagree. It's not a flaw, it works as designed and it's designed as it should. It seems that some grid control of ASP.NET 2.0 can't deal with this. IMHO it's not my fault that that grid is written by incapable people. After all, it never should throw the exception it does, either because: - ITypedList is implemented: the grid should use it, period - ALL the types in the grid have a common base type. (ObjectEntity). The grid should use that base type for the columns to generate.

Some time ago I stopped with making some stupid grid's poor code my problem as it's of no use: I can't fix it, the programmer(s) who wrote it should. Unfortunately, Microsoft thinks no-one is bitten by their bugs so they don't think anyone needs fixes for their code.

See for example Conceptual Schema and Relational Database Design (G. Nijssen / T. Halpin)

Well I don't agree with everything this particular book says.

IMHO, you should. Nijssen and Halpin are icons in the relational model world.

But I understand what you are saying. Why have inhertiance if the supertype cannot be used seperately in other tables not joined the that particaulr subtype. I have been successfully doing it this way for years and it makes my life alot easier. Every invoice, user, customer, etc has a record in Object table.

That then brings me to where I am. So I can live with not pulling up the supertype in an entity collection if there are more then one subtype's of it.

Please don't make a crash in some poorly written grid MY problem. You can perfectly pull subtypes AND supertypes in an entity collection, that works GREAT. However databinding with an asp.net 2.0 gridview might not work because that grid is too stupid.

BTW why do you allow it in the designer then?

I don't understand the question?

Anyway, I am probably going to using another method anyway to grab lists of data and I want to be able to use LLBL to edit save individual objects.

With that said, under my current scenario. I have object records that belong to many different 1:1 entities that I would like to inherit, because it's easy to pull up one object that has all the necessary fields. Can I say that as long I don’t try to fetch and entity collection that has multiple subtypes, I wont have any other problems.

You can fetch them without problems as well. It's just that binding them to a grid AND automatically discover columns doesn't work because the grid is not capable of doing that.

Inherited. Object <- User <- ManagerUser Object <- Application

Can I use the ManagerUser object fill it and save it without any problems or am going to have to disconnect this for the inheritance?

Of course you can do that without problems. That's the whole point of having inheritance support.

I am ok without being able to have a list of ObjectEntityCollection filled on a webpage. Nice that it works on the winform. But again, if I add a record in ManagerUser I should get 1 record in each Manageruser User and Object tables. If I pull one up it will pull up that 1 record and modify that one record for each and not error out.

It will do that, a bound gridview of asp.net seems to inable to visualize it due to lack of some code in the grid, which should be there, as it simply should use the ITypedList implementation on the entityview returned by the bound entitycollection (which is what winforms grid do and why it works there).

Though you will NEVER be able to see ManagerUser fields in a grid to which you bind an ObjectEntity collection, for the simple reason that grids work like: - determine the columns - fill the rows

which thus means that if you have a type which doesn't have all the fields related to all the columns, it can't visualize the cells for these fields obviously.

BringerOD wrote:

Otis,

Thanks for you help on this issue. I have been thinking some more. It's just that I can't figure it out. Why would you need inheritance at all in LLBL?

Take a step back and re-read WHERE the exception occurs, then re-read my explanations WHY it occurs. It's the GRID which is at fault here, not my code. My code works fine, you can use inheritance without any problems. It's just that databinding in grids with a collection with supertypes AND subtypes is a problem, because 1) due to the nature of how grids work in .NET (see above) 2) due to the lack of support code for standard interfaces for databinding in the asp.net grid you used.

I mean if I can’t reuse the data structure of the supertype in another subtype, why does it at all. I am just confused as to when you are going to suggest using this. Why not just create the one table instead of inheriting from another table, if that supertype cannot be used in another subtype.

Just because some asp.net 2.0 grid is poorly written, doesn't mean the inheritance feature is flawed. On the contrary.

(edit) To show you the contrast: When I bind an EmployeeEntity collection to a GridView in ASP.NET 2.0, I get the same error as you, which is expected, as the collection contains employees, managers and boardmembers. These types are there because when I fetch an EmployeeEntity collection, I request all EmployeeEntity objects, and a Boardmember is-a EmployeeEntity so it's there. It also fails when I simply pre-define a column in the grid and set AutoGenerateColumns to false in the grid properties. I.o.w.: the code inside the grid isn't the most cleverest on the planet.

Next I add an ASPxGrid from DevExpress to the form. I pre-define a column in the grid, e.g. Id (which is the PK field, defined in Employee). And I bind the same EmployeeEntity collection to the grid.

It works. No crappy error about type mismatches, simply because a typemismatch error is silly, and the makers of that grid know that.

I didn't get it.

Now I do.

Thanks.

I haven't tested but I can assume what will solve it is that you add the columns at design time and switch off autogenerate columns in the grid properties. This will make the grid simply ask the returned entity view for the properties it KNOWS (which you designed), it doesn't have to reflect over the types in the bound object.

The above is not entirely true. You can never refer to the PrimaryKey field that is linking all the tables together (and therefore cannot delete/update)! Here is what is happening.

Lets say you have the following tables in your heirarch:

Parent.ParentId Parent.Name Parent.Address

Child.ParentId Child.Location Child.Spouse

Attach a LLBLGenDataSource to ParentCollection. Create a grid with the following columns: Name and Address. Put a delete button on the grid too, for later testing. Be sure AutogenerateColumns=false Run the webpage and everything will work fine.

Add the ParentId column to the grid. Run the webpage - and it will give the Object does not match target type. (Same exception that is in the first post of this thread)

Remove ParentId column from the grid. Run the page and display the grid. Click the delete buttion and you will get the IndexOutOfRangeException exception from the first post in this thread. (the DataKeyName property in the grid is set to ParentId)

So it appears you cannot use a LLBLGenDataSource at all with an inheritance hierarchy if you need access to the primary key (update/delete operations). (You can display the primary key if you use a templated column to show it)

Can you advise Otis?

You can't bind a collection with multiple types to a grid on a webform. that's basicly it. (The binding succeeds, but the grid goes bezerk when it sees the second type. )