i've opened a seperate thread - i've added odp multi criteria support, fixed a few bugs on linq (the source for a newer version wasn't available) and added a small featur - enabling to set via config that proxies should reconnect a session if it is disconnected instead of throwing an exception.
i'd love to add my stuff to the project just tell me how
i'd also love to contribute anything you need (i actually prefer the hard stuff...)
up until now i was working on stuff that will help my team in our project but i have a few ideas on what more can be done:
1. currently, fetch="subselect" cannot be overidden in a specific query, the other way around is true also, if fetch="join\select" we can't use subselect for a specific query. the reason is the design is quite different - there is a special intializer for fetch="subselect" assosiation. i think the way to go is a different design, where subselect will be a fetch mode just like join and select, and a criteria will be able to set the initializer for the collection.
2. when an object is evicted from the session and then re-entered by update, if it has a collection, will update all of the collection instead of updating just the updated once. i can see why this is happining - nhibernate have no way of knowing if someting had changed while the object wasn't persisted. the solution, i think, is using reflection emit, and when fetching any object, creating a class that inherites from that object and adding a state management in that class. the idea is very similar to proxies, and i think it will be very nice feature - if an object is re-persisted, nhibernate still knows exactly what is new and what is updated. nhibernate will also won't have to check the primary key value for knowing if the object is new, it will simply use the state
3. i've noticed that when fetching a value from a sequence, nhibernate is using a seperate select. at least with oracle, i know that we can add select s.next_val from dual within the actual insert command. the problem is that nhibernate won't know the id afterwards. well, thats why i think such a feature could be configureable - in the sequence config, the user can specify that he doesn't care what is the id value and then nhibernate will do as i said. the object won't be persisted afterwards, but may be this should be the user choice to make
4. when a session flushes, i think returning the rows effected is a very reasonable idea! currently, in my project we're using optimistic lock, where we enable multiple user to concurrently work on the same object, and when it is saved, if there is a concurrency fault, the user will be notified. to do this we have to query the DB before using the Id and the timestamp to find out if our data is not stale. if we could update the entity using the id and the timestamp, we could save the DB access (and a query on a reletively big table), and if no rows were effected - we have a concurrency fault.
5. this brings me to another idea - enabling update not only depending on the id of entity, but on another property (for our case it will be the timestamp property).
if some of my ideas make sense, or if you have any other job to give me i'll be happy to do so :) i actually enjoy this.
also get back to me about the multi criteria for odp
my mail firstname.lastname@example.org