I have a situation whereby I would like to create a query against an entity using EclipsLink JPA, I require 5 fields from this entity of which it has many. 2 of those fields are joined OneToMany relationships. I only require 2 primitive fields from each of the joins.
What is the most efficient way to do this?
I've considered a number of possiblities, batch reading seems the best bet based on what I have read however I believe this will only work if I retrieve the full entity i.e. SELECT a FROM Entity a... and the reason I don't want to do this is I have LOB and BLOB types that will eat dangerously into the memory.
Join-fetch is another but the entity has ~10 joined tables and I don't want to duplicate all of this data.
I have been using fetch groups (http://wiki.eclipse.org/EclipseLink/Examples/JPA/AttributeGroup) and specifying the fields I want which causes cached lazing loading. This is workable and the memory footprint is better. The issue is though when I do entity.getCollection() it must do a single SQL statement for each call and this is where I feel it is inefficient. If I could do SELECT a.Field, a.Field2 from Entity A using some form of batching or join-fetching or better still apply this to my fetch group this would be best I would imagine but not sure if I could ensure that it would not load all related tables and only give me the ones I want.
Help/thoughts would be much appreciated.
I think batch fetching with also work with nested fetch groups, did you try this?
You can also set a defaultFetchGroup on your FetchGroupManager (either directly or by adding fetch=LAZY to your fields you do not want in your fetch group, i.e. add fetch=LAZY to your LOB fields).
Related
I am working on my first project using an ORM (currently using Entiry Framework, although that's not set in stone) and am unsure what is the best practice when I need to add or subtract a given amount from a database field, when I am not interested in the new value and I know the field in question is frequently updated, so concurrency conflicts are a concern.
For example, in a retail system where I am recording a sale, as well as creating records for the sale and each of the line items, I need to update the quantity on hand of the items sold. It seems unnecessary to query the database for the existing quantity on hand, just so that I can populate the entity model before saving the updated quantity - and in the time taken for that round-trip, there is a chance that the same item will have been sold through another checkout or the website, so I either have a conflict or (if using a transaction) the other sale is blocked until I complete my update.
In SQL I would simply write
UPDATE Item SET Quantity=Quantity-1 WHERE ...
It seems the best option in this case is to fall back to ADO.NET + stored procedure for this one update, but is there a better way within Entity Framework?
You're right. ORMs are specialized in tracking changes to each individual entity, and applying those changes to the DB individually. Some ORMs support sending thechanges in btaches, but, even so, to modify all the records in a table implies reading them all, modifyng each one, and sending the changes back to the DB as individual UPDATEs.
And that's a big no-no! as you have corectly thought. It implies loading all the rows into memory, modifying all of them, track their changes, and send them back to the DB as indivudal updates, which is way more expensive that running a single UPDATE on the DB.
As to the final question, to run a SQL command you don't need to use traditional ADO.NET. You can run SQL queries directly from an EF DbContext using ExecuteSqlCommand like this:
MyDbContext.Database.ExecuteSqlCommand('Your SQL here!!');
I recommend you to look at the MSDN docs for Database class, to learn all the things that can be done, for example managing transactions, executing commands that return no data (as the previous example) or executing queries that return data, and even mapping them to entities (classes) in your model: SqlQuery().
So you can run SQL commands and queries without using a different technology.
I'm creating a webservice layer over a legacy SQL Server based system. It's a pretty large and complicated business application which has a large number of stored procedures that perform SELECT statements . Most of these stored procedures join a number of tables and produce a single resultset for easy consumption by the client.
In building my webservice I want to take advantage of EF, and using a Code First approach 80% of my use cases can be achieved by mapping direclty to tables. However I have a number of use cases where I need the cross tbale views of data as provided by the stored procedures. As I see it I have 3 options:
Create new POCOs that represent the stored procedure returns and link these to the existing stored procedures (let SQL do the join and re-use exisitng code)
Create new POCOs that look like the stored procedure return, but populate themselves by association with othe EF entities (let EF do the jons)
Do the joins somehow in LINQ
What do people think is best practice in situations like this, which I guess most of us are coming up against everyday?
Thanks,
Andy
many a good book out there. anything from Julie Lerman... this is more recent http://www.apress.com/9781430257882
With Navigation properties, you can do most things without old fashioned joins.
So 4) do it in Linq,and let EF do the Joins.
Use Navigation properties. you can do many logical joins and even avoid the join keyword.
this blog shows how easy and why LINQ with no join syntax results in Joins at the db level.
http://blog.staticvoid.co.nz/2012/7/17/entity_framework-navigation_property_basics_with_code_first
I have some tables which should add to my database every year and name of databases contains the year (like sell2005) and iv'e written some ef queries on these tables ,and queries can only be on a single entity (like sell2005) but what should i do when sell2006 or sell2007 add ? how can i manage them with that single query which iv'e written before?
thank you.
There is no easy way. EF is simply not tool for this scenario. For EF you must have "single table" so you must either use partitioning with one real database table partitioned by year or you must build a view on top of these tables.
The problem is that in EF you have strict relation between classes and tables. You cannot have single class mapped to multiple tables even if they are exactly same (except inheritance which is not solution for you). So the workaround would require to have multiple SSDL/MSL mappings - one for each table and construct correct context instance with correct mapping for every query. As I know dynamic changes of mapping are not possible (except modifying SSDL/MSL files before using them).
I'm trying to display the results of a sproc in my MVC 3 web app.
However, the sproc calls into 4 tables on one database and joins them with 5 views (single table views only, thank goodness) on another database. Each (SQL Server) db is on a separate server but that shouldn't matter.
I've read this: http://blogs.msdn.com/b/swiss_dpe_team/archive/2008/02/04/linq-to-sql-returning-multiple-result-sets.aspx
and this:
http://www.codeproject.com/KB/dotnet/linqToSql5.aspx
and still cannot determine whether I should use the dataContext classes or just embed the straight SQL.
Perhaps there is a better way to return my results than LINQ to SQL (15 columns, 3 different data types)? I need to update the tables as well. The user will have the ability to update each value if they choose. Is this a task best suited for the entity framework classes?
I plan on using the repository pattern so I can change data access technology if I must but would rather make the correct decision the 1st go 'round.
I was hoping for a resource that was more up-to-date than say, NerdDinner and more robust than the movie apps for MVC3 that abound, particularly implementing the sproc results inside a view. Any suggestions would surely be appreciated. Thanks.
Once you plan to "update" data then you are going to handle it all through stored procedures. Both Linq-to-sql or Entity framework will not help you with this because they are not able to persist changes to something created from arbitrary query. You should very carefully check if you are even able to track the data back to the correct record in the correct table. Generally result of a stored procedure is mostly for viewing the data but once you want to modify the data you must work with each table directly or again use some stored procedure which will do the task. Working with tables from multiple databases can be pretty complex in entity framework (EF doesn't support objects from multiple databases in one entity model).
Also what you mean by 15 columns, 3 different data types? Stored procedures support in both Linq-to-sql and Entity framework will return enumeration of one flattened data type containing 15 properties.
I'm not aware of anything that linq-to-sql can do that Entity Framework can't really, so EF seems to be a better solution in this case. You can add a stored procedure to your Entity Framework model as well, so you can just have it call the procedure and deal with whatever comes back.
Since the end goal will involve accessing the same Databases with either technology and they will be using sql to retrive the data either way its really a subjective anwser.
I would use whatever technology you are most comfortable and focus more on the implementation. Both data access platforms are based off of ado.net technologies and are for the most part equally powerful.
Regardless of the technology I would evaluate how the data is accessed and make implementation decisions based on that.
We plan on using identity columns in our sql server database. Currently we are using guids to generate unique ids, but it turns out that the ordering is relevant so we consider switching to identity columsn.
Since ordering is relevant we want to make sure that the order in which we add objects to the entity context is also the order in which they are inserted into the database. This is relevant since sql server will be generating values for the identity column.
Is this guaranteed by the entity framework? If not, what is an efficient solution to generating your own unique integer ids for a database that is being updated from different processes.
I am just guessing here (although it should be pretty easy to test), but I don't think EF can guarantee the order. I am pretty sure that the internal structure is based on an IEnumerable type, probably a List, which are just enumerated during insert, and enumeration is as far as I know not guaranteed to be in the same order every time.
I would instead add a dedicated "sort order" column to your database table and take it form there.
I wouldn't rely on the insert order as the order of your records returned. Sure, it'll work most of the time, but what if you ever need to insert a row somewhere? I'd say your best bet is to add an ordinal column and actively generate ordinals for each row as you'd like them to be returned.