Greetings, If I understand ConcurrencyPredicateFactoryToUse correct, this predicate is applied when SAVING an entity and hence it is an excellent too to automate "Optimistic Concurrency". This kind of predicate automation is so handy that I came to a senario where I needed a similare predicate factory to be applied when READING an entity from the databse. Senario: invoices table has invoice for DepartmentA and DepartmenB. When reading an invoice entity from the database, I want a predicate for the department field. This predicate factory should be applied even when the object is being loaded into a collection. Is it possible to build this type of predicate automation...

If you want that, you have to use FetchNewEntity, which accepts a filter, and produce teh filter with a factory.

you have to use FetchNewEntity, which accepts a filter, and produce teh filter with a factory.

Two senarios: 1- If the UI programmer creates an EntitCollection and then requests the BL to fill it from the DB, how can I automate the inclusion of a filter bucket whenever the EntitCollection calls the entitie's factory to create a new object of this entity

2- In my BL's derived entity class, I want a filter bucket factory to automatically include its filter bucket for every fetch operation for that entity.

The nice thing about ConcurrencyPredicateFactoryToUse is that its consulted AUTOMATICALLY at save without me having to worry about how I am saving the object. If there was a FetchPredicateFactoryToUse then that would act the same when FETCHING the object from the DB.

omar wrote:

you have to use FetchNewEntity, which accepts a filter, and produce teh filter with a factory.

Two senarios: 1- If the UI programmer creates an EntitCollection and then requests the BL to fill it from the DB, how can I automate the inclusion of a filter bucket whenever the EntitCollection calls the entitie's factory to create a new object of this entity

The fetch as you describe it should get a filter created by the BL code, if I understand the scenario correctly.

Though that's not transparent, admitted. What you want if I understand it correctly, is that when you fetch an entity of type E, a filter for the PK should be used (which is the current situation) PLUS a filter supplied by a factory, transparently, or when you fetch them in bulk, there should always be a filter applied on a given set of fields besides the supplied filter.

Is that a good description? So in fact you want to define an entity collection as a collection which isn't generic, it's a container for a special set of objects, defined by the filter factory added to the collection.

2- In my BL's derived entity class, I want a filter bucket factory to automatically include its filter bucket for every fetch operation for that entity.

The nice thing about ConcurrencyPredicateFactoryToUse is that its consulted AUTOMATICALLY at save without me having to worry about how I am saving the object. If there was a FetchPredicateFactoryToUse then that would act the same when FETCHING the object from the DB.

I'll add it to the todo for the may release. I think it will be obsolete by then due to the implementation of inheritance/multi-table mapping, but we'll see

Though that's not transparent, admitted. What you want if I understand it correctly, is that when you fetch an entity of type E, a filter for the PK should be used (which is the current situation) PLUS a filter supplied by a factory, transparently, or when you fetch them in bulk, there should always be a filter applied on a given set of fields besides the supplied filter.

Is that a good description? So in fact you want to define an entity collection as a collection which isn't generic, it's a container for a special set of objects, defined by the filter factory added to the collection.

Thats exactly what I meen . What I am trying to do is a sort of Data access security so that if a UI user is fetching a collection of invoice objects, a filter is appended to his request assuring that these invoices are ONLy for departemt (x) (the department of the current user).

I'll add it to the todo for the may release.

can't wait...

I think it will be obsolete by then due to the implementation of inheritance/multi-table mapping

can you please elaborate how table inheritance can help in such a situation..

omar wrote:

I think it will be obsolete by then due to the implementation of inheritance/multi-table mapping

can you please elaborate how table inheritance can help in such a situation..

I think it can help in such a way that you could define a new entity type based on that relation you defined and which thus combines multiple tables together. I'm not sure if it really fits your particular situation, but it could. (though I'll still try to implement your suggestion )

I guess I have to wait and see the table inheritance in action..

(though I'll still try to implement your suggestion )

Thanks..

Frans:

Did you ever add the following?
If so, where did it end up?

Otis wrote:

I'll add it to the todo for the may release. I think it will be obsolete by then due to the implementation of inheritance/multi-table mapping, but we'll see

We have an application we are developing and one of our requirements is that we inject a SecurityPredicate at each record/recordset fetch operation. We are looking for the best place to insert this.

We noticed that we can use the OnFetch() for single record retrievals, but there is not an equivalent "OnGetMulti".

We are using the 2-Class Self-Servicing arch but were considering switching to the DataAdapter since that seems like it would lend itself better for this particular issue. Is our assessment correct?

Would DataAdapter be preferable for our situation?

Thanks.

That's indeed preferable I think.

Inheritance is indeed implemented in 1.0.2005.1. It's however not recommended to create 1 base table and derive all entities from that base table. This gives slowdowns at runtime as you've to join with that base table no matter what you do.

Otis wrote:

Inheritance is indeed implemented in 1.0.2005.1. It's however not recommended to create 1 base table and derive all entities from that base table. This gives slowdowns at runtime as you've to join with that base table no matter what you do.

What about for TargetPerEntityHierarchy? Could we then create one "base" class and derive all entities from that base table?

In the past we have created an "unmodeled" class and just "injected" it into the class hierarchy, which we can still do, but since the TPEH existed, I thought we would use that instead. Which way would you recommend?

Thanks,

Andrew.

I think you mean TargetPerEntity, right?

Walaa wrote:

I think you mean TargetPerEntity, right?

No, I think I mean TargetPerEntityHierarchy, unless I'm reading the docs incorrectly.

My understanding is as follows:

TargetPerEntity: (what I call TPE) If I have 2 classes: Base and SuperBase - when requesting a "SuperBase" entity, an INNER JOIN will be created between 2 Tables, Base and SuperBase to provide me with the resultant composite of data

TargetPerEntityHierarchy: (what I call TPEH) If I have 2 classes: Base and Superbase - when requesting a "SuperBase" entity, no JOIN is performed, because all "attributes" from "Base" already exist in "SuperBase" so only one table is SELECTed against.

Is that correct?

I would not think I would have performance issues for TPEH - I can see issues that could exist with TPE if the inheritance tree goes very deep.

Andrew.

It's easier to explain the difference between them by another approach.

TargetPerEntity: Where you have a database table for each type in your heiarachy, which means you have a table for the Super entity, and a table for each sub entity, related to each other by PK-FK relation. And the relation is only 1-1. so the PK of the sub table PK is also the FK to the super table PK.

When fetching a SubType entity Joins are made all the way to the root entity.

TargetPerEntityHierarchy: You only have One database table for all you types, super type and sub types refer to that table, and there is a discriminator field to define the type of each row.

When fetching a SubType entity No Join occurs as you've explained.