Ok, finally light at the end of the tunnel!

• Inheritance implementation is done, besides compiler checks for vb.net templates (to check if the conversions from C# are done ok). I'm extremely happy with the end result, and I'm sure you all will be too. After porting the graph visualizer to v2.2 of the Netron lib, it works even nicer, and I really had to resist myself not spending another week adding all kinds of visual stuff
• Mapping more than one entity on the same target: done
• Auto-hide m:n relations setting: done
• Toggle hide flag on m:n relations- plugin: to be done next week.
• Type converters (random .NET type of a type coverted to a different .NET type at runtime, so you can map a boolean field on an Oracle number(1,0) field or a Guid on a char(32) string ). Gui elements still to be add, but groundwork is done. Will be pretty ok, I hope to have working code tomorrow evening, so that's on schedule
• Minor things, like paging in prefetch paths using Marcus' code: still to be add, next week (but not a lot of work)
• Fixes of issues in 1.0.2004.2: next week
• Minor things to be add (20 or so) which take very little time to add: next week
• Operator overloading for C#: next week (implementation is half done)
• .lpt include templates in TDL templates: minor TDL interpreter addition, should be done next week.
• tests to see if current code works without breaking with the new code: next week (unittest runs)

I hope it will all be done in the 1st week of september. During beta period I'll use the time to fix bugs as well, so it might be that I will postpone some bugfixes till the beta starts, but that's not that much of a problem.

There are a few performance problems in the designer still, which I have to iron out, but with my Ants profiler that should be a minor thing.

I'll keep you all posted

Dude! I'm stoked!

can't wait for this. I just hope FRANS can show us a real life example of how to use the new inheritence features...

omar wrote:

can't wait for this. I just hope FRANS can show us a real life example of how to use the new inheritence features...

I ran into a nice example the other day. A library! You have a lendable item, and derived from that all kinds of different items: books, movies, games, magazines etc. Books can be derived into adult, child, comic etc. Any graph which contains types where the instances can't change their type is a good one. A bad example is for example my example in the other threads where I used employee, manager, clerk and boardmember. It helped me create the code, but the graph itself isn't well defined, because what happens when a manager gets promoted to boardmember?

A book will never become a magazine, in the library example.

Another example of where inheritance can help is where you have several types, but only one has a give relation with another entity. Through inheritance you can create that situation. For example, if you have a hierarchy mapped onto a single table (with a discriminator column), you can derive one entity type and create a custom relation, all the other entities don't have that relation (though derived types of that entity with the relation of course derive that relation ).

It's funny but I have an application now where there is more than the usual amount of this kind of thing. Of course we are all familiar with company-->vendor and person-->employee, but in this app almost every major entity can have different flavors.

It's for doing completions for oil wells. A well's borehole might be "cased" or "open hole". Each one requires a different type of completion job. Then if the job uses a rig, it will have certain attributes, but if not it will have others. And it just goes on and on.

omar wrote:

can't wait for this. I just hope FRANS can show us a real life example of how to use the new inheritence features...

I'm thinking about using it for a task manager. And when I say task manager, Outlook ain't got nothin on this. To me, EVERYTHING is a task and most tasks are comprised of smaller tasks. A web project is a task. Buying groceries is a task. Washing the car is a task. Yet all of these tasks have different work flows and properties.

alexdresko wrote:

omar wrote:

can't wait for this. I just hope FRANS can show us a real life example of how to use the new inheritence features...

I'm thinking about using it for a task manager. And when I say task manager, Outlook ain't got nothin on this. To me, EVERYTHING is a task and most tasks are comprised of smaller tasks. A web project is a task. Buying groceries is a task. Washing the car is a task. Yet all of these tasks have different work flows and properties.

Ok.. I see where you are going with this. But isn't this better addressed using state-machines

omar wrote:

Ok.. I see where you are going with this. But isn't this better addressed using state-machines

Heh, I dunno. What's a state machine and how is it better than Fran's inheritance model?

Otis wrote:

Ok, finally light at the end of the tunnel!

I know this has been a big one! Well Done!

Otis wrote:

There are a few performance problems in the designer still, which I have to iron out, but with my Ants profiler that should be a minor thing.

How do you find the Ants profiler? I used it once on a big ASP.NET project... it crashed and I never gave it another chance! The ReSharper people JetBrains released a new profiler http://www.jetbrains.com/profiler/ which I was thinking of buying.

Marcus wrote:

Otis wrote:

Ok, finally light at the end of the tunnel!

I know this has been a big one! Well Done!

I'm not there yet! .

Still a lot of work to do, but the majority of stuff is done. (I hope . Never know what kind of 'hmm, this doesn't work in this scenario'-bugs are ahead of me)

Otis wrote:

There are a few performance problems in the designer still, which I have to iron out, but with my Ants profiler that should be a minor thing.

How do you find the Ants profiler? I used it once on a big ASP.NET project... it crashed and I never gave it another chance! The ReSharper people JetBrains released a new profiler http://www.jetbrains.com/profiler/ which I was thinking of buying.

I find it a bit simplistic (ants). It's fairly stable though. I always used NProf, but that was too unstable after a while. What I find good about ants is that it's fast, you won't notice much delay in having an app profiled. The main thing I find sad is that you can't have it profiling a running app starting at a giving time, like you have some slow routine deep down in a running application which pops up after a while. To profile that, you have to keep theprofiler running all the time, which pollutes the results.

alexdresko wrote:

omar wrote:

Ok.. I see where you are going with this. But isn't this better addressed using state-machines

Heh, I dunno. What's a state machine and how is it better than Fran's inheritance model?

The idea of a state machine is that a program exists in a finite number of possible states and that something happens to transfer the program from one state to the other. An excellent article on the subject is by the Dan man (Dan Appelman). He even has a StateCoder library that is worth considering.

http://www.desaware.com/tech/statemachineintro.aspx

the stateCoder framework http://www.desaware.com/products/universalnet/statecoder/index.aspx

I've written some state machines in the past (I love the pattern ) but I don't really see how a state machine can replace entitytype inheritance. You could replace entity type inheritance with a decorator-style pattern though.

Otis wrote:

I ran into a nice example the other day. A library! You have a lendable item, and derived from that all kinds of different items: books, movies, games, magazines etc. Books can be derived into adult, child, comic etc. Any graph which contains types where the instances can't change their type is a good one. A bad example is for example my example in the other threads where I used employee, manager, clerk and boardmember. It helped me create the code, but the graph itself isn't well defined, because what happens when a manager gets promoted to boardmember?

Ug...

At least to me when doing modeling the derived objects come out of behaviors not attributes. While a magazine and a movie might be different and distinct things they are not really a place where I would model a class hierarchy since they have the same behaviors. They are really all lendable items with different attributes. See Object Thinking, by David West.

They do seem to pass the Is-A test but do they have different behaviors.

You’re not really going to create a Class hierarchy that contains all those items are you?

I know you are just looking for an example.

BOb

Otis wrote:

I ran into a nice example the other day. A library! You have a lendable item, and derived from that all kinds of different items: books, movies, games, magazines etc. Books can be derived into adult, child, comic etc.

Wow, i'm going to have to have a closer look at this for my hobbyist application... keep up the good work.

Geoff.

pilotboba wrote:

Otis wrote:

I ran into a nice example the other day. A library! You have a lendable item, and derived from that all kinds of different items: books, movies, games, magazines etc. Books can be derived into adult, child, comic etc. Any graph which contains types where the instances can't change their type is a good one. A bad example is for example my example in the other threads where I used employee, manager, clerk and boardmember. It helped me create the code, but the graph itself isn't well defined, because what happens when a manager gets promoted to boardmember?

Ug...

At least to me when doing modeling the derived objects come out of behaviors not attributes. While a magazine and a movie might be different and distinct things they are not really a place where I would model a class hierarchy since they have the same behaviors. They are really all lendable items with different attributes. See Object Thinking, by David West.

They do seem to pass the Is-A test but do they have different behaviors. You’re not really going to create a Class hierarchy that contains all those items are you? I know you are just looking for an example.

Let me first say, that I too find that inheritance for entity types should be done with care and only then when it truly adds something, and in some cases it might be that it looks like it does, but it's really not true, as you argue with the library example. The example is really just an example, but I think it still is a good one, because for example, a dvd is in 2 parts: the box in the rack and the dvd disc behind the counter. So the box number has a related disc number. (example). This relation is thus present only in the dvd type (or '2-part element type') and not in the book type, as the book is just 1 item.

To be able to make this relation only be present in some elements and not in others, you need different types. This can be overcome with another setup, true, but it doesn't have to.

One of the reasons why inheritance wasn't implemented from the beginning was that I didn't find it really necessary, as after all, the relational model in the db doesn't show any inheritance.

Though, after a while I found it a missing element from the functionality, as I couldn't model the entities as my ORM/NIAM model, so supertype/subtypes weren't available, only flattened models. It gives more flexibility to the user what to do with the db, it's no longer '1:1 mirroring the datamodel in the db'. Together with the typeconverters, it can become quite interesting (type converters for example allow you to write with 10 lines of code a converter which converts byte[] types which result from Image columns/blob fields to .doc objects or .jpg objects and vice versa, transparently . everything is possible. )

About the type converters: I've now working my first type converter, which converts byte/int/long/ulong/uint/short/ushort/sbyte to bool and back. So I can do: myCompanyCar.HasDrawHook = true; and save it on oracle, where it is converted to '1' as HasDrawHook is mapped onto a NUMBER(1,0) field. As this is in the persistence info, when I would use the same code on sqlserver, a bit value would be send Fetching does the same, but back to bool (every value > 0 is true, 0 is false). This type converter is an example, you can write your own with very few lines of code.

This is more powerful than you might think. What about string encryption? I can write a typeconverter which converts string to string but encrypts / decrypts them. As the type converter is compiled with the entity's persistence info, this is transparent: setting the field(s) which have the converter set (you can set them per entity/typed view field) to a string will encrypt them when the field is updated, and decrypt them when the field is read from the db.

This also works with typedlists, dynamic lists, typed views and entity collections fetched as datatable: I've now my own datatable filler routine, which converts when required.

I'm not yet sure if nullable type converters are possible, but it should: converters which work with magic values, for example a converter which converts -1 to NULL when saving to the db. I think it will be a great feature . (and it will be great to see how long it will take the competition before they include it ).

The conversion is very fast, but depends on the converter code of course, so no real delays should be encountered.

Otis wrote:

One of the reasons why inheritance wasn't implemented from the beginning was that I didn't find it really necessary, as after all, the relational model in the db doesn't show any inheritance.

Though, after a while I found it a missing element from the functionality, as I couldn't model the entities as my ORM/NIAM model, so supertype/subtypes weren't available, only flattened models. It gives more flexibility to the user what to do with the db, it's no longer '1:1 mirroring the datamodel in the db'.

I totally agree. It is actaully one of the features of the product I really didn't want to loose since I decided to move from NHibernate due to it being non-supported, beta status, not well documented.

Your product was very compelling. With this addition it will be more so.

I wonder if you plan to solve the other two drawbacks of LLBLGen Pro that I see when designing from an Object Model first perspective.

1. The ability to only include the properties in the Entity object that you want. This will come in handy when using legacy data model such as I am. We have a table that is overloaded and is related to many parents. I want to be able to create a specific child Object for each parent and only include the relevent fields of the db. In other words can I remove mapped properties. I can't seem to do it in the current version.

2. The second side is being able to create an Entity that is a subset of a table as a child entity. This isn't as needed. An example would be a Customer table that has address data in the same table so rather than mapping all the address fields as propeties of the Customer entity mapping them onto an Address entity and mapping an Address property on the customer entity of type Address.

Any plans to handle the above two issues?

I certainly look forward to the beta and will be one of the first customers to download it I am sure.

Thanks, BOb

Otis wrote:

One of the reasons why inheritance wasn't implemented from the beginning was that I didn't find it really necessary, as after all, the relational model in the db doesn't show any inheritance.

Well, my plan for it, and this may be a workable example for others is as follows.

I have an HR / Payroll ap. In this app we have various types of people such as Employees, Contacts, Dependents, Beneficiaries, COBRA Participants, etc.

Currently in our database we have an Employee table, which has SSN, Address, etc. Well, when the Employee terminates they become a COBRA Participant. Problem we have from a Db perspective is duplication of data. Let's say the Employees address changes. Well, now, due to our data model they have to update the address in two places.

Another issue is that a person can be an employee for more than one company. So, we create a second Employee record for them. Of course, in this case they have the same SSN, so we are not able to create a unique constraint on the SSN field, which we really should have.

So, to fix these issues and others I want to normalize the data out so that I have a Person table. This will store the common items such as SSN, Address, etc.

But, from an object perspective I don't really have a "Person" entity in my domain. I have an Employee entity. However, when I want to persist this I need it to save to the Person table for the SSN, Address, dob, etc. And the Employee info like empnumber, company, start date, job, etc to save to the Employee table.

I hope this is one thing this feature will allow me. I fell I will have to have the Person entity but I will mark it as abstract so that it will never be instantiated. Can I do this?

So, will the new version you are working on allow for the above. Or, am I misunderstaning what the inheritence feature will give me?

BOb

pilotboba wrote:

Otis wrote:

One of the reasons why inheritance wasn't implemented from the beginning was that I didn't find it really necessary, as after all, the relational model in the db doesn't show any inheritance.

Well, my plan for it, and this may be a workable example for others is as follows.

I have an HR / Payroll ap. In this app we have various types of people such as Employees, Contacts, Dependents, Beneficiaries, COBRA Participants, etc.

Currently in our database we have an Employee table, which has SSN, Address, etc. Well, when the Employee terminates they become a COBRA Participant. Problem we have from a Db perspective is duplication of data. Let's say the Employees address changes. Well, now, due to our data model they have to update the address in two places.

Another issue is that a person can be an employee for more than one company. So, we create a second Employee record for them. Of course, in this case they have the same SSN, so we are not able to create a unique constraint on the SSN field, which we really should have.

So, to fix these issues and others I want to normalize the data out so that I have a Person table. This will store the common items such as SSN, Address, etc.

But, from an object perspective I don't really have a "Person" entity in my domain. I have an Employee entity. However, when I want to persist this I need it to save to the Person table for the SSN, Address, dob, etc. And the Employee info like empnumber, company, start date, job, etc to save to the Employee table.

I hope this is one thing this feature will allow me. I fell I will have to have the Person entity but I will mark it as abstract so that it will never be instantiated. Can I do this?

Yes. Just define an FK between the Employee PK and the Person PK, and llblgen pro will find the inheritance automatically . You then have an EmployeeEntity which inherits Person's fields and you can work with Employee from then on.

Currently there's no feature to mark a type 'abstract' in the designer, though that's planned for this version (if the entity is in a hierarchy and has subtypes and if not root, supertype is also abstract.)

So, will the new version you are working on allow for the above. Or, am I misunderstaning what the inheritence feature will give me?

For situations like this, it's especially useful. As you stated before, it can bite you, when for example you inherit more types from Person and an employee can also be one of these types.

Otis wrote:

Yes. Just define an FK between the Employee PK and the Person PK, and llblgen pro will find the inheritance automatically . You then have an EmployeeEntity which inherits Person's fields and you can work with Employee from then on.

Cool exactally what I want... Ok, if Person / Employee is releated in the db, how does it know if this is an Inheritence relation verses a Parent/Child relation?

Otis wrote:

For situations like this, it's especially useful. As you stated before, it can bite you, when for example you inherit more types from Person and an employee can also be one of these types.

Thanks. Can you comment on the issues in the post from 30-aug-2005 15:41:01.

BOb

pilotboba wrote:

Otis wrote:

Yes. Just define an FK between the Employee PK and the Person PK, and llblgen pro will find the inheritance automatically . You then have an EmployeeEntity which inherits Person's fields and you can work with Employee from then on.

Cool exactally what I want... Ok, if Person / Employee is releated in the db, how does it know if this is an Inheritence relation verses a Parent/Child relation?

It doesn't construct a hierarchy by default, but it will, if you use the option to do so. It will consider any 1:1 PK - PK relation a hierarchy relation (so no 1:1 PK - FK/UC relation is considered, only PK - PK relations (which are always 1:1).

Otis wrote:

For situations like this, it's especially useful. As you stated before, it can bite you, when for example you inherit more types from Person and an employee can also be one of these types.

Thanks. Can you comment on the issues in the post from 30-aug-2005 15:41:01.

Yes, will do shortly. I didn't see that posting at first

pilotboba wrote:

Otis wrote:

One of the reasons why inheritance wasn't implemented from the beginning was that I didn't find it really necessary, as after all, the relational model in the db doesn't show any inheritance.

Though, after a while I found it a missing element from the functionality, as I couldn't model the entities as my ORM/NIAM model, so supertype/subtypes weren't available, only flattened models. It gives more flexibility to the user what to do with the db, it's no longer '1:1 mirroring the datamodel in the db'.

I totally agree. It is actaully one of the features of the product I really didn't want to loose since I decided to move from NHibernate due to it being non-supported, beta status, not well documented.

Your product was very compelling. With this addition it will be more so.

I wonder if you plan to solve the other two drawbacks of LLBLGen Pro that I see when designing from an Object Model first perspective.

1. The ability to only include the properties in the Entity object that you want. This will come in handy when using legacy data model such as I am. We have a table that is overloaded and is related to many parents. I want to be able to create a specific child Object for each parent and only include the relevent fields of the db. In other words can I remove mapped properties. I can't seem to do it in the current version.

This is one of the new features in 1.0.2005.1

1. The second side is being able to create an Entity that is a subset of a table as a child entity. This isn't as needed. An example would be a Customer table that has address data in the same table so rather than mapping all the address fields as propeties of the Customer entity mapping them onto an Address entity and mapping an Address property on the customer entity of type Address.

This isn't part of 1.0.2005.1, and I've to think about adding it to 2.0. I'm not really sure if it adds much value.