-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 
Author Message
 Post subject: How to select both properties and objects in single ICriteri
PostPosted: Fri Sep 28, 2007 10:01 am 
Beginner
Beginner

Joined: Mon May 14, 2007 2:50 am
Posts: 22
First question:
is it possible with hql write this query:
Code:
"select c, c.name, c. address from Company c"
, that is, i want to select in single query both properties, and the object.



Second question would be (if answer to first one is "possible") can i make it work with ICriteria?
At the moment i am selecting only the needed properties using projections, but i don't find any info of how to select both properties and the object.

I tried with setResultTransformer, but seems that projections and result transformer do not work together

Any thoughts on this?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 28, 2007 8:17 pm 
Regular
Regular

Joined: Wed Oct 25, 2006 10:51 pm
Posts: 71
I don't think what you're asking to do makes any sense.
It looks like your confused between the world of objects and sql queries.

If your HQL is just "from Company" you get the object and therefore you get it's associated properties. You don't have to query for both.

And with criteria:

Code:
IList<Company> companyList = session.CreateCriteria(typeof(Company)).List<Company>();


If you're using projections, elsewhere, then that should have been part of your initial question.
But I can't understand, if you're going to the extent of using projections (presumably for some minor performance gain) then why bother with it, if you need the whole object anyway?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 29, 2007 3:38 am 
Beginner
Beginner

Joined: Mon May 14, 2007 2:50 am
Posts: 22
Quote:
But I can't understand, if you're going to the extent of using projections (presumably for some minor performance gain) then why bother with it, if you need the whole object anyway?

:)

You hit the right spot.

I use projections for performance gain, and a very big performance gain.
We have a program where you can choose whatever columns you want to view in a datagrid. And those columns can be chosed whatever you can trace in the object graph, having that you only go only via one-to-one relationships (i.e. the "one" side of the "one-to-many" relationship).

Say, we are viewing a collectin of Teaching Group objects. Then in the grid we can choose any properties from the object graph, for example:
    group object properties
    Group.TeachingProgramme properties
    Group.GroupLeader properties
    Group.GroupLeader.Company properties
    etc.


The problem is that if we have very big object graph, the it gets extremely slow to load all object graph.
We did tests withs 15k objects (which is not much), and we had around 15 seconds delay to load all those objects, and then display in the grid.


After making projections, so that it instead of loading 15k object graphs, we select only the properties we display in the grid. The time went down to 3-5 seconds. That is, the performance gain was 3 to 5 times. That's alot.

So that's why we use projections.

Now why do i want to select the object. Basically, the idea is this:
When we had objects in the grid, we did not have to query for them when we pressed edit or delete buttons. We already had the objects, so no need to loag again.

Now, as we have only properties in the grid, we load an additional column Id, so that we could know which object we want to edit or delete. Thus, before invoking edit or delete command, we have to query for the object.

Now, the biggest problem is that the programming paradigm shifted - the grid now contains not the objects, but the properties and ID of the object. If it would be possible to select both properties and the object (only the root object, without any relationships), the way we programming would not have to change - The grid would always return the object it is showing, and not the Id of that object.

Now, i do not say this is the best my though ever in my life :D
It's just brainstorming. As far as i think, the performance would not suffer alot for selecting one object without any relationships, but it would help as have our API more consistent.

Just random thoughts :)


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 29, 2007 9:37 am 
Regular
Regular

Joined: Wed Oct 25, 2006 10:51 pm
Posts: 71
Right,

NHibernate does use a 'cache' to store all your objects, so it's gonna cost a bit to fill this up. But a fast PC and loads of memory should eat this up pretty fast. But then again, I don't have any queries returning 15,000 rows, so what do I know.

There's also could be a design issue here, as I see it. It sounds like you're loading your domain objects straight into your grid.
We often use a DTO (Data Transfer Object) to pass information back between the UI and the presenter.
To go from domain object to DTO, we use a DtoMapper which takes domain model classes, and creates a list of DTO objects from it.

If we didn't do this, as you didn't, I can imagine that the grid could possibly be filled with an enormous load of (possibly) memory wasteful domain objects - possibly even duplicating object trees (by accident) for every row.

I would suggest giving DTO's a try, if there's any chance your grid product is not coping with the memory load.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.