In my business domain I need to do something with n-th child object which is inserted for a given parent object. So for examples some business actions should be invoked after inserting 100th, 200th and 300th child.
For now I have an idea to add a number field for children so the first child (for a given parent object) gets 1, the second gets 2, ... and so on. How may it be achieved using NHibernate? Or maybe there are better ways to achieve my goals.
Thank you in advance for answers and ideas.
Best regards
Lukasz
You can map your collection as a <list>... so the index of the children is stored.
Then you can use an AddChild method to add elements, so you can execute custom logic when you reach the n-th child.
Related
Good afternoon everyone!
I'm studying NHibernate, and decided to make some changes. Among them, I noticed that some fields are unnecessary. So I bring my doubt:
I have a list, let's call it Class_List within each study class, I can have N students for each class. Within the list Class_List, I also have other properties as simple as the name of the class.
How I see it is unnecessary to store how many students I have in the database, I would, in a single query, how many records I have. This, using NHibernate.
Is this possible? How?
Best regards,
Gustavo.
Edit: I've forgot to say one thing... I want to return this number of record, as a column. But this column is not mapped in my .hbm.xml file.
If students are mapped as a collection on Class, you can try using something like this:
var numberOfStudents = session.CreateCriteria<Class>()
.Add(Restrictions.IdEq(1))
.CreateCriteria("_students", "students")
.SetProjection(Projections.RowCount())
.UniqueResult<Int32>();
Where '1' is the id of the class (you can use other property) and '_students' is the name of the students collection.
I'm using Core Data for a tableview. My data is ordered by the distance from your current location. What I'd like is to have a new section for items with 5, 10 and 20 miles.
My distance value is stored in the data store as an NSInteger and I get it out using a NSNumber in my object model.
I've done a bit of searching around and found that I need to use the sectionNameKeyPath attribute to make the data sectioned.
My problem is that I don't know the best way to group the data. During my searches I came across either a transient property or using a category of NSNumber to work out which section the item should be in.
Are either of these methods the best way of getting my end result, if so, can anyone provide any details on how to implement it?
Thanks.
You should add a derived attribute to the object (it's not strictly needed in the model), let's name it range. I'd make it a read only property, you can cache the value or not.
When it's 0-5, return 5, 5.x - 10 return 10, etc.
Then set range as your sectionNameKeyPath.
If you want a highly customized section behavior, you need to subclass NSFetchedResultsController to give you the behavior you want. See the NSFetchedResultsController class docs for details.
You will need to subclass in this case because your not looking at a single ordered attribute like the alphabetized first letter of a string attribute but rather a range in which each attribute falls into.
This is a cleaner solution than altering the data model because you can use it to display the data many different ways in many different tableviews without having to muddy up your data model.
I've got a table in my database storing items:
Items
-------
ItemID
Name
...
Etc
and a separate table storing the PK of two different items from the first table. I want to be able to list the one item, and then any number of related items. I've tried searching for examples but haven't found much surprisingly...
RelatedItems
------------
ItemID
RelatedItemID
If I have four products, whose IDs are 1, 2, 3 and 4... and 1 is related to 2 and 3 I might have data that looks like this:
ItemID RelatedItemID
1 2
1 3
4 1
I am then modeling them in the Entity Framework Designer, and the designer automatically adds an association from the Items table to itself (many to many). The designer also adds two navigation properties, if I use the first property on Item #1 I get all items where Item #1 is in the first column, and if I use the second property I get all the items where Item #1 is in the second column.
I however just want to have one navigation property where I can say Items.RelatedItems and it returns all the items that the above two properties would when combined. I know I can join the two results after the fact but I can't help to think I'm doing something wrong and there is a better way.
Hopefully this is all clear enough.
It sounds like SQL schemas just aren't very good at modeling the concept you're looking for. The schema you've chosen would work well if you want to establish a directional relationship (item A is related to item B, but item B may or may not be related to item A). If you were looking for a grouping-style relationship (Items A and B are in the same group), I can think of a different approach you'd use. But I can't think of a good way to model an inherently bi-directional relationship using a traditional relational database.
Some workarounds might be to use a View that joins the two results, or to use triggers to make sure that every mapping from A to B has a corresponding mapping from B to A, so that both of the properties always return the same objects.
If you have an instance of an Item, call it item, then the following will give you the related items...
item.RelatedItems.Select(ri => ri.Item);
Your RelatedItems property on item (ie the first navigation property you mentioned) will be a collection of RelatedItem objects, each of which has two navigation properties of its own, one of which will be named Item and will be a link to the related item.
Note that this is air code, as I'm not in front of anything I can test this on right now, but I think this will do what you want.
If you want to make it simpler, you can write an extension method to wrap up the Select(), something like this...
public static IEnumerable<Item> RelItems(this Item item) {
return item.RelatedItems.Select(ri => ri.Item);
}
Then you could just do...
item.RelItems();
Note that I couldn't name the extension method RelatedItems, as that would clash with the navigation property that EF would have created for the second table. That's perhaps not a good name for that tables, as it's not the actual items, rather the IDs of the items. Either way, the above code should work.
Under one UnitOfWork (session) I may call CreateCriteria twice. My first call is to populate a grid for data editing. Let's say the data has been edited and flushed (saved) to the database and the grid is still open. After the data is edited, I may call CreateCriteria a second time to retrieve a list of objects that are validated and found in error.
Lets say ObjectA was retrieved by both calls to session.CreateCriteria. It was edited in the grid but found in error within the second list.
The first question would be: Considering first level cache, is ObjectA--that was retrieved from the second call to CreateCriteri--represent the one retrieved from the first call? or, better yet, did NHibernate "detect and reuse" ObjectA from the first call assuming the keys did not change?
To my final point in question: I want to edit ObjectA which was found in error, and let's say it was brought up in a ListBox. Therefore, I want to highlight that object, call session.Get()(key) in order to retrieve it from cache, then bring up a change form to change ObjectA's properties. Which object am I changing? The one from the first call to CreateCriteria or the second call? Are they the same?
Thank you in advance.
Second level cache
Take a look at http://ayende.com/Blog/archive/2006/07/24/DeepDivingIntoNHibernateTheSecondLevelCache.aspx and http://www.javalobby.org/java/forums/t48846.html
From the former:
The second level cache does not hold
entities, but collections of values
So, with caching setup properly, NHibernate will be able to recreate your object without having to get the actual values from the database. In other words, the object will be created the same as when it wasn't in cache, except that since the values are cached, NHibernate won't actually query the database since it already knows what's in there.
I'm not quite sure what you mean by "validation" and "found in error". Are you validating before insert? Typically my entities are validated before the insert/update and won't actually be inserted/updated if invalid.
Validation aside, what I think you're asking is that if you:
save something
do a flush
retrieve an item (from a new session) with the same key as the one saved in step 1
will you be retrieving the same reference to the object you saved in step 1(?). And the answer is no since NHibernate does not cache the OBJECT but rather the values so it can create a new entity populated with the cached values (instead of actually performing a DB query).
However, does that really matter? If you overload Equals such that equality of 2 entities are based on their ID, then finding the same (not reference equal, but same) item in a grid (or a hash of any kind) should be a snap.
First level cache
I didn't realize you were talking about 1st level cache. 1st level cache works as an identity map and does cache the instance of the object. Therefore, if you do 2 selects from the db based on the same ID, you will retrieve the same instance of the object.
I've developed an application that populates a treeview from hierachical data in a database.
I've designed it to use lazy-loading so it only gets the child nodes when a node is expanded.
My problem is that obviously I don't know if a node has children unless I make a call to the database and look. Currently I have implemented a dummy child node, so that the [+] icon appears for all nodes, I then remove this dummy node and get the real child nodes in the BeforeExpand event.
This means I get a [+] icon for nodes that don't have child nodes, so the user clicks the expand icon and there's nothing show which looks a bit shoddy.
What is the preffrred method for handling child nodes in a lazy-load treeview? If I make a call to the database to see if there are child nodes then I might as well just load the child nodes and forget about lazy loading right?
One thought I had was to store a 'HasChildren' flag in the database, so I can selectively create my dummy child node only for the nodes that actually do have child nodes.
Sorry for rambling on, I'm very interested to see what other people think...
When you make a call, check for children along with the node data:
SELECT tp.*,
(
SELECT 1
FROM table tc
WHERE tc.parent = tp.id
LIMIT 1
) AS has_children
FROM table tp
You don't have to count, it may be long.
Just check that at least one child exists.
change your initial query to return all the same data, but also a count of children. when the children count is not zero show the [+]. post your schema and query for help getting the count
My preferred solution to this problem is to implement pre-ordered tree traversal on your set of hierarchical data. See http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/ for an example implementation.
The point is that if you maintain a left and right value for each node, then if the left value and right value differ by more than one, that node has children.
The only notable downside of this approach is that you have to actively maintain those left and right values when altering the structure of the nodes.