I have a query that starts at the QueueItem and, if the entity that Queue Item references is an E-mail, adds some additional filter conditions. One of those conditions is the primary field value of whatever that e-mail, in turn, is "Regarding". I don't really care what type of entity the E-mail references, I just need to allow the user to filter by the "Name" of that entity. Is this possible, and if so, how?
This depends somewhat from where the query is performed from.
With a basic FetchXML query, in around about sort of a way this is possible, you need to do joins on the relationship and see if there is a record there. Its not perfect but it might work.
If you are running the query from code, then its a bit easier as you can examine the entity type in code. For example:
EntityReference e = entity.GetAttributeValue("regardingobjectid");
string entityName = e.LogicalName;
Related
Hi I was building an app and was wondering on how I can convert this query into a derived query method without using the annotation #Query:
SELECT address, COUNT(*) address FROM `employee` GROUP BY address ORDER BY address DESC LIMIT 5
I have tried it here is how I did it
List<Employee> countByAddressGroupByAddressByOrderByAddressDescLimit5();
This throws the following error
Invalid derived query! No property groupByAddressBy found for type String! Traversed path: Employee.address.
I was wondering if what am I doing wrong here thank you in advance.
I don't think query derivation supports group by.
You can't.
Derived queries don't support GROUP BY.
Derived queries are intended only for simple queries, where the mapping between a normal method name that you might choose independently from Spring Data and the query needed for implementation is obvious.
For more complex cases like the one you describe other mechanisms are available, like annotated or named queries. Nobody wants to use a method name like countByAddressGroupByAddressByOrderByAddressDescLimit5 anyway.
As others said, derived queries do not support this. There might be other reasons besides simply not being a 'practical' solution.
AFAIK derived query methods are restricted to retrieving instances just for the entity type managed by the repository (you can retrieve MyEntity, Optional<MyEntity>, Collection<MyEntity>, etcetera) or projections that match the fields/columns used for the managed entity.
When you use 'Group By', you break with this resultset structure, you usually have to explicitly indicate which columns you want to retrieve or which operations you want to perform on the grouped columns (which would be impossible using just a method name).
TL;DR
You can't easily indicate the columns you want to include in a 'Grouped By' query result, so no, I don't think there is a way to use this technique with 'Group By'.
I'm new to Spring JPA.
I has two questions about Example and ExampleMatcher API.
Are there any ways to ignore all paths except some paths which I set matchers. Or are there any ways to ignore all paths if Example object's path has null value. It is quite annoying to set all path names like below:
ExampleMatcher<Product> matcher =ExampleMatcher.matching().ignorePaths("field_a", "field_b");
How to match joined column using Example. For example. Product entity has User entity field as #ManyToOne relation. User entity has several fields but my Example object has User field only filled with userId field. In this case I want to find product data which has user_id foreign key column matching userId field value included in user object included in product Example object.
Sorry for poor English... Actually this is my first question at Stack Overflow.
Thanks for attention.
I'm looking forward for great answers.
Spring Data by default will ignore null values in properties. So you need not ignore paths for null values. We could also use the withIgnoreNullValues() (docs) method call on the matcher to explicitly tell it to ignore null values.
Note primitive values(int,double,etc) if not set will still be used since primitives can't have nulls and use default values instead so you should ignore the primitive properties if not used for matching.
For your second question, you could do something like the below
Product product = new Product();
User user = new User();
user.setId(5); // Id to be matched
product.setUser(user); // Associate User object with Product
Example<Product> example = Example.of(product,matcher);
I have a generic group members table with a GUID for a "group type" and a GUID for "referenced object". An example would be if I have a table of customers(each having a GUID) I can group them under "already paid" by creating a group GUID and in my "Group members table" referencing every customer by their respective GUID. This allows for any type of group to be added to the model as we expand(without adding extra tables).
Here is the problem. I have created a subquery in an entity in order to filter the universal group members table for a certain group and what "items" are and are not in that group; like so:
partial void ElementsNotMemberOfGroup_PreprocessQuery(int? UniversalGroupTypeIDParameter, int? UniversalGroupsIDParameter, ref IQueryable<UniversalGroupMember> query)
{
query = query.Where(x => x.UniversalGroup.UniversalGroupType.UniversalGroupTypeID == UniversalGroupTypeIDParameter);
query = query.Where(x => x.UniversalGroup.UniversalGroupsID != UniversalGroupsIDParameter);
}
This returns the GUIDs for the referenced object in the group, but for a user that's useless. I need to join this table and my customers table at runtime on the GUID so I can extract the customer info and display it.
Any Ideas?
LightSwitch wasn't really created with this kind of scenario in mind. LightSwitch makes things very easy for you when you create relationships between tables that are, well, "related". When you do this, you never need manual joins between entities.
While it's possible to do something similar to what you're describing (see the link below), it's a lot more work to achieve it, and in my opinion it isn't really worth the extra trouble. Not only that, but as you're discovering, it complicates even the most simple operations.
In essence, you're working against LightSwitch, instead of with it. My advice to you would be that if you really must do this type of manual optimization, then LightSwitch may not be the best product for you to use.
Beth Massi has a blog article, Using Different Edit Screens Based on Record Types (Table Inheritance), which isn't exactly what you're doing, but it may give you some ideas if you decide to still use LightSwitch for your project.
In a data model like this (http://alanstorm.com/2009/img/magento-book/eav.png) I want to get the value from an EAV_Attribute using Linq to SQL.
Assuming that an EAV_Attribute only exists in one inherited table (varchar, decimal, int, etc.) how can I get it in a linq query?
I know that I can use the Inheritance for this, but I want to execute it in the SQL Database side...
Is it possible to do a kind of Coalesce in Linq, considering that the elements have different types?
EAV and linq is not a happy marriage. I think your best shot is to create an unmapped property in eav_attribute that resolves the value (as object) from it's typed attribute child. With entity framework, you won't be able to use this property in an expression (i.e. not in a Where or Select), You must convert to IEnumerable first to access it. (Linq-to-sql may allow it because it can switch to linq-to-objects below the hood).
Another option is to create a calculated column of type sql_variant that does the same, but now in t-sql code. But... EF does not suport sql_variant. You've got to use some trickery to read it.
That's the reading part.
For setting/modifying/deleting values I don't see any shortcuts. You just have to handle the objects as any object graph with parents and children. In sql server you can't use cascaded delete because it can only be defined for one foreign key. (This may tackle that, but I never tried).
So, not really good news, I'm afraid. Maybe good to know that in one project I also work with a database that has an inevitable EAV part. We do it with EF too, but it's not without friction.
First of all, I recommend using TPH and not TPT for EAV tables. (One table with multiple nullable value columns (one per type) + discriminator vs. one table per type.)
Either way, if you modelled the value entity as an abstract class (containing the two IDs) with an inheriting entity per value data type that adds the value property, then your LINQ should look like this:
var valueEntity = context.ProductAttributes.Where(pa =>
pa.ProductId == selectedProductId
&& pa.AttributeTypeId == selectedAttributeTypeId)
.SingleOrDefault() as ProductAttributeOfDouble;
if valueEntity != null
return valueEntity.Value;
return null;
Where the entity types are: Product, AttributeType, ProductAttribute, ProductAttributeOfDouble, ... ProductAttributeOfString.
In Microsoft Dynamics CRM 4.0, I want to be able to check if a record of any entity type is disabled. I think I can check the statecode. From the information I have seen, a value of zero means that the entity is enabled (editable in CRM) and any other value means disabled (for editing in CRM).
Is this assumption correct for all entities?
EDIT
If my assumption is correct, is it possible to create a QueryExpression for dynamic entities that does such a comparison, rather than using the text, "Active", which would be incorrect for quotes?
From what I've read, StateCode is not necessarily the same for every entity. It varies per entity.
I'm not aware of a way to disable an entity. I double checked our install, but don't see any option to disable. Google also yields no results to this end.
Do you mean perhaps individual entity records? If so, you'll have to check the StateCode for the entity you're looking at. I think most entities use StateCode as you describe, but for some entities, such as Activities, it seems to vary a little.
Here is some SQL I found to pull back the StateCode/StatusCode details of a particular entity:
select
AttributeName,
AttributeValue,
Value
from dbo.StringMap
where
(dbo.StringMap.AttributeName = 'statuscode'
or
dbo.StringMap.AttributeName = 'statecode')
and
dbo.StringMap.ObjectTypeCode = 1
ObjectTypeCode 1 maps to the Account entity.
Hope this helps.
EDIT: Just saw your addition. I think you'll be safe using StateCode in most instances. I personally use it in one of my projects to exclude disabled records on the Lead and Contact entities. Just double check the value mapping as I've described and then implement.