I like what I've seen so far of your product. It seems WAY easy to use (without being simple ). I've had a hunt around on the forum but a lot of the threads seem to be very technical and very specific, I guess understandably. So, anyway... I was wondering if you could describe, in general terms, how I'd go about the following tasks: 1. Adding a permanent (i.e. available on every instantiation) property, eg. name as a concatenation of first and last. 2. Returning the results of a union (I can see that I can create a sp, is there another way?) and, given that the union results are from the same db table, do updates to the data get persisted to the db? 3. Adding a 'summary' property, eg. adding order total from order details to the order. 4. Returning the grandchildren of the current 'record', eg. returning all a customer's order details.

Thanks in advance.

ChicagoKiwi wrote:

I like what I've seen so far of your product. It seems WAY easy to use (without being simple ). I've had a hunt around on the forum but a lot of the threads seem to be very technical and very specific, I guess understandably. So, anyway... I was wondering if you could describe, in general terms, how I'd go about the following tasks: 1. Adding a permanent (i.e. available on every instantiation) property, eg. name as a concatenation of first and last.

In selfservicing, use two-class scenario and add your property to the derived entity class. In Adapter, derive a new class from an entity class and from it's factory. As this is a bit cumbersome, the upgrade, which is almost in beta, offers regions for customization code in the generated code to preserve code between code generation cycles.

1. Returning the results of a union (I can see that I can create a sp, is there another way?) and, given that the union results are from the same db table, do updates to the data get persisted to the db?

You can have multiple fetches to the same typedlist,typed view or entity collections. It depends on what you're using (adapter or selfservicing) what you've to do to keep the existing data. Which of the two are you using, selfservicing or adapter?

1. Adding a 'summary' property, eg. adding order total from order details to the order.

This is not yet supported in entities through the designer, create a dynamic list for this. The plan was to add this support for the upcoming upgrade but it took longer than expected to create the expression editor so this is postponed till april/may.

1. Returning the grandchildren of the current 'record', eg. returning all a customer's order details.

You can do that easily by creating an OrderDetails collection and a filter on the customerid in order. It depends on what you use (selfservicing or adapter) so I can give you an example implementation. Also it depends on the amount of data in your database what to choose: a join with filter or a subquery with filter.

Otis wrote:

Also it depends on the amount of data in your database what to choose: a join with filter or a subquery with filter.

Frans,

Just for my own learning, is there a good rule of thumb for your above statement?

MarcoP wrote:

Otis wrote:

Also it depends on the amount of data in your database what to choose: a join with filter or a subquery with filter.

Frans,

Just for my own learning, is there a good rule of thumb for your above statement?

Well, say you want to fetch all employees who have checked in orders in a given period of time. If there are a lot of orders and few employees, a join will result in a lot of duplicate rows: select e.* from employees e inner join orders o on e.employeeid = o.employeeid where...

if distinct can't be used, because e contains a blob, the duplicates have to be filtered out on the client. This can be slow. In that case, this is much faster: select * from employees where employeeid in (select employeeid from orders where...)

In general, rdbms's can optimize joins better than subqueries, though in situations like this, subqueries are much faster.

I'm not sure which paradigm I'm going to use - at this stage I'm only looking... I guess I'll go with Adapter since that gives more flexibility. Is there a reason that you'd give not to go with Adapter, apart from personal perference?

ChicagoKiwi wrote:

I'm not sure which paradigm I'm going to use - at this stage I'm only looking... I guess I'll go with Adapter since that gives more flexibility. Is there a reason that you'd give not to go with Adapter, apart from personal perference?

If your app will be 2-tiers and not using remoting, it's often easier to use selfservicing as it is less typing and you get typed collections out of the box and lazy loading.

Having only two tiers doesn't completely fill me with dread, and I'm not using remoting. That said I'd like to have a central repository for all the non-GUI "stuff" and still retain the ability to re-generate the LLBL Gen project. Does that then preclude using self-servicing?

ChicagoKiwi wrote:

Having only two tiers doesn't completely fill me with dread, and I'm not using remoting. That said I'd like to have a central repository for all the non-GUI "stuff" and still retain the ability to re-generate the LLBL Gen project. Does that then preclude using self-servicing?

No, that doesn't mean you should drop selfservicing, it only needs some more dicipline . In a gui class, you have to make sure you call your central repository for things like getting entities and persisting data, not doing Save() or fetching in the gui class, because it's so simple to do with Selfservicing .