Hey Frans,

I know that you've only just finished a rather marathon feature addition to the product and you are probably due for a decent breather, but (always a BUT!) can you give us a heads up on your product plans and timing for the rest of the year?

BTW, I think that this latest set of changes has really taken the product to the next level. It was extremely useful before, now its just plain indispensible

takb wrote:

I know that you've only just finished a rather marathon feature addition to the product and you are probably due for a decent breather, but (always a BUT!) can you give us a heads up on your product plans and timing for the rest of the year?

Not too much time for a breather . First new database drivers will be added for a couple of databases. Then the designer will be upgraded with features currently already available in the runtime libraries such as expressions, much more advanced typed list editor, readonly columns in entities, custom fields in entities, multi-catalogs in projects etc. After that, it's probably first inheritance and then the compact framework. We'll be in december/jan by then. CF support and inheritance support (in runtimes and designer) will both be added, it's a matter of how fast the other features can be added

BTW, I think that this latest set of changes has really taken the product to the next level. It was extremely useful before, now its just plain indispensible

Thanks!! I think so too, I'm very happy with the result and with ever feature I wonder: why didn't I implement this from the beginning, but then again, there is only a fixed amount of time and resources of what you can do

Hope you takin it slow now for the rest of the week.

After that, it's probably first inheritance and then the compact framework

I know what inheritance is but i do not undestand you mean with "inheritance"?

You can already inherit from Entities and Collections.

Inheritance as in: person entity, a customer entity inheriting from person entity, queries based on type etc.

Are you planning on supporting both methods of inheritance?

Method #1: Single table with columns for all sub-types, FK to sub-type designator Method #2: Single table with base type columns, one table for each sub-type

By the way, supporting this kind of inheritance in a generated framework is genius. I'm not sure if you're the first to do it, but this will be one of the "I can't live without this" features - as soon as it comes out.

Jeff...

All I can say is, wow.

jeffreygg wrote:

Are you planning on supporting both methods of inheritance?

Method #1: Single table with columns for all sub-types, FK to sub-type designator Method #2: Single table with base type columns, one table for each sub-type

Method 1 is not recommended due to the FK to self, which can lead to a lot of overhead which isn't necessary, as all columns are already in the record (base and derived class columns). Method 2 is indeed one of the mapping methods which will be added, together with these 2: Method #3: single table with all columns of all classes in a hierarchy plus one column with a type identifier. This is already possible in code in adapter Method #4: one table per type with all the columns accessable in the type.

By the way, supporting this kind of inheritance in a generated framework is genius. I'm not sure if you're the first to do it, but this will be one of the "I can't live without this" features - as soon as it comes out. Jeff...

Well, inheritance in O/R mapping is often demanded but not often required nor necessary. The reason for that is that as soon as you go the inheritance route, you can say goodbye to the dynamic resultset feature a relational model is so good at. In other words: it's a powerful feature but you can shoot yourself in the foot quite easily. A result of this can be that it won't be possible to simply delete a set of entities directly in the database but that you have to pull them out of the db first.

Otis wrote:

jeffreygg wrote:

Are you planning on supporting both methods of inheritance?

Method #1: Single table with columns for all sub-types, FK to sub-type designator Method #2: Single table with base type columns, one table for each sub-type

Method 1 is not recommended due to the FK to self, which can lead to a lot of overhead which isn't necessary, as all columns are already in the record (base and derived class columns). Method 2 is indeed one of the mapping methods which will be added, together with these 2: Method #3: single table with all columns of all classes in a hierarchy plus one column with a type identifier. This is already possible in code in adapter Method #4: one table per type with all the columns accessable in the type.

Oops, my method #1 is your method #3 . By "sub-type designator" I meant "type identifier".

By the way, supporting this kind of inheritance in a generated framework is genius. I'm not sure if you're the first to do it, but this will be one of the "I can't live without this" features - as soon as it comes out. Jeff...

Well, inheritance in O/R mapping is often demanded but not often required nor necessary. The reason for that is that as soon as you go the inheritance route, you can say goodbye to the dynamic resultset feature a relational model is so good at. In other words: it's a powerful feature but you can shoot yourself in the foot quite easily. A result of this can be that it won't be possible to simply delete a set of entities directly in the database but that you have to pull them out of the db first.

What are some other consequences of using the inheritance feature?

Jeff...

jeffreygg wrote:

Otis wrote:

jeffreygg wrote:

Are you planning on supporting both methods of inheritance?

Method #1: Single table with columns for all sub-types, FK to sub-type designator Method #2: Single table with base type columns, one table for each sub-type

Method 1 is not recommended due to the FK to self, which can lead to a lot of overhead which isn't necessary, as all columns are already in the record (base and derived class columns). Method 2 is indeed one of the mapping methods which will be added, together with these 2: Method #3: single table with all columns of all classes in a hierarchy plus one column with a type identifier. This is already possible in code in adapter Method #4: one table per type with all the columns accessable in the type.

Oops, my method #1 is your method #3 . By "sub-type designator" I meant "type identifier".

Ok No FK I hope

By the way, supporting this kind of inheritance in a generated framework is genius. I'm not sure if you're the first to do it, but this will be one of the "I can't live without this" features - as soon as it comes out. Jeff...

Well, inheritance in O/R mapping is often demanded but not often required nor necessary. The reason for that is that as soon as you go the inheritance route, you can say goodbye to the dynamic resultset feature a relational model is so good at. In other words: it's a powerful feature but you can shoot yourself in the foot quite easily. A result of this can be that it won't be possible to simply delete a set of entities directly in the database but that you have to pull them out of the db first.

What are some other consequences of using the inheritance feature? Jeff...

First that you get tables with data without context. This means that if I have the following: - Employee table - Manager table with 1:1 relation with Employee and 1:1 relation with CompanyCar - CompanyCar table

the manager table has no context. It contains data, but it is not an entity on its own, data belonging to the entity is also stored elsewhere. Say I store a manager. I then add 2 records, one to employee and one to manager. The record in employee is the record of a manager. What happens if I delete the record in the manager table? The employee which was a manager is now not a manager anymore, at least not according to the database.

This can be a non-issue if you target the database with just 1 O/R mapping layer and no other application. But with larger databases, often multiple applications are targetting the same database, often a subset of the data. For these applications the data means nothing, it looks weird, disorganized. This is a big problem and often ignored by O/R mapper purists, but once you have inherited (pun intended) an application with a legacy database and the database is in a format only understandable by a tool, you know how important it is the relational model has to be based on a theoretical correct model.

Second, data is just that: data. One golden rule in IT is that there is a difference between data and information. Data can become informatoin, or better: you can distillate information out of data. So the context in which data is used is key to make it mean something. A list of orders with their customer's company name is a simple example of how obviously random data can become meaningful information. Looking closer it shows that the information is build with data from different sources.

When you have a database that is build with all kinds of contextless tables, you have a hard time creating lists . The only way then is to make lists from fields from entities. This is simple, on paper. But when you have a 5 class high inheritence tree and a field you want to use in a list is defined in the top class but you define it using the bottom class, it will cause a 5 table join to get the field. This is not visible for the developer (nor should he/she care). This is also the reason why most O/R mappers totally ignore lists and other types of data-usage. They only focus on classes.

Third: (which is related to the second item) I found it hard to come up with an example in which inheritance was required to make it a good system. I had it on the list of features to be added in the very first release, but no matter how hard I looked, I couldn't find a good example in which it was required. With required I mean: if you don't include inheritance, your system is of a very low quality and development is cumbersome. I'm not a great Fowler/Evans fan and the domain model is not what I think a good way of developing software so that's perhaps the reason I don't see it. For decades hundreds of thousands of developers have written database driven applications without inheritance but WITH proven technology based on the work of Chen and Yourdon for example.

One of the reasons I didn't find a good example was that it made me feel locked up in a fixed harness. Data doesn't have context, however by using inheritance, it did get context, it was not usable in another context. What if I need it in another context? (the dreaded person <- customer, person <- employee example where employee becomes customer?) I then can't use the data, I have to copy it, the ultimate sin in database land.

Another one was that the inheritance hierarchy often relied on data in the model. Alter the data, the hierarchy falls apart. This is odd, if you consider a relational model without any data is still the same relational model. In the 'hierarchy per single table' option, you have a type column. What if I alter a value in that column? I can do that, it's data. The data will be the same, the relational model won't care, but the data in the table is unusable from that point. Not because of business rules violation, I can imagine that, but because the data can't be loaded (!).

I haven't even talked about polymorphism of data (yes, some people really think that should be possible ), in which field Foo has meaning A in the base class but meaning B in the derived class, and it could be that Foo is stored in the separate class per type for the derived class, perhaps with a different type. My personal opinion with that is that it's asking for trouble. Big trouble