I have an entity that has a string property called Tags. I would like to query this entity based upon if a certain string is located in Tags property.
So for example, I would have a function IList GetEntityByTag(string tag), this would return all Entity's that have the value of tag in their 'Tags' property.
I tried going through the ICriteria approach... Expression.In(PropertyName, Value) but this is the exact opposite. I need something like Expression.In(Value, PropertyName).
Perhaps IQuery would be a better strategy but I have not been able to find any type of HQL statment for Property CONTAINS 'abc'.
Any help or point of direction would be great thanks!
If you want to know if a tag is a substring in your Tags property, you might want to consider these tips:
You might want to convert both the string you are searching in and searching for to lowercase first. Expression.ilike does this for you. Score.
To find out if your search term is anywhere in the field, you can set the MatchMode parameter in the ilike function to MatchMode.ANYWHERE.
If, as you commented earlier,
let's say my property, 'Tags' =
a;b;c;d;e. I want to know if 'a'
exists in tags. Will
Expression.Like("Tags", "a") return
true?
If 'a;b;c;d;e' is a string, Expression.ilike( "Tags", "a", MatchMode.ANYWHERE ) will return true.
Do you mean Expression.Like(PropertyName, Value)?
Related
I have a node Country. I know that this node has some properties, but I don't know which. I mean, I know since I've take a look at model. Here is what I've found in documentation:
Country
name: String
iso_2_code: String
iso_3_code: String
region: String
sub.region: String
I know that if I run
MATCH (c:Country)
RETURN c.iso_2_code
I'll get result for one specific property. Is there a query that would as a result return me something like: name, iso_2_code, iso_3_code, region, sub.region?
If I didn't have access to the model how could I list all of the properties that are attached to some node type?
Answering more from a Cypher or openCypher perspective than for a specific implementation. Using the air-routes dataset. There are three things to consider.
Firstly if you know the properties you want, as you mentioned, you can just ask for them explicitly.
MATCH (a:airport {icao:'KDFW'})
RETURN a.city, a.desc
However, if you want all properties, but do not want to list them all, you can just do:
MATCH (a:airport {icao:'KDFW'})
RETURN properties(a)
If you just want the property keys:
MATCH (a:airport {icao:'KDFW'})
RETURN keys(properties(a))
Lastly, if you want the properties plus the label and ID information you can just do:
MATCH (a:airport {icao:'KDFW'})
RETURN a
I have a database called students with columns like so
In my rails model with a scope or function, I would like to select for the single age value based on the id. The id column is unique. So something like
scope :get_age, -> (id) { where(id: id).select(:age) }
However this does not seem to work. I would like for the returned value to just be the int 12. Using something like pluck ends up returning an array which I would like to avoid. How would I go about selecting for just the value of 12?
you know that for one id there is just one row (or no rows) so using where or pluck is not ideal, we want something it returns one row or nothing (find, find_by etc)
def self.get_age(id)
find_by(id: id)&.age
end
some_id = 10
User.get_age(some_id)
Scoping allows you to specify commonly-used queries which can be referenced as method calls on the association objects or models. With these scopes, you can use every method previously covered such as where, joins and includes. All scope bodies should return an ActiveRecord::Relation or nil to allow for further methods (such as other scopes) to be called on it.
Reference: https://guides.rubyonrails.org/active_record_querying.html#scopes
That's why is not working as you expected.
I think the best alternative would be to do as Ursus suggested. Create a method, a query object, etc.
You basically want to read an attribute(age) of your model object. For that, you don't need to write any specific method or scope.
Here is what you can do in the place where you have the id and you want to fetch the age for that record:
object = YourClass.find(id)
object.age
Can someone tell me why in NHibernate mapping we can set access="field.camelcase", since we have access="field" and access="property"?
EDIT: my question is "why we can do this", not "what does it mean". I think this can be source of error for developper.
I guess you wonder what use field.camelcase have when we can do the same with just field? That's true, but that would give (NH) properties unintuive names when eg writing queries or reference the property from other mappings.
Let's say you have something you want to map using the field, eg
private string _name;
public string Name { get { return _name; } }
You sure can map the field using "field" but then you would have to write "_name" when eg writing HQL queries.
select a from Foo a where a._name = ...
If you instead using field.camelcase the data, the same query would look like
select a from Foo a where a.Name...
EDIT
I now saw you wrote "field.camelcase" but my answer is about "field.camelcase-underscore". The principles are the same and I guess you get the point ;)
the portion after the '.' is the so called naming strategy, that you should specify when the name you write in the hbm differ from the backing field. In the case of field.camelcase you are allowed to write CustomerName in the hbm, and NHibernate would look for a field with name customerName in the class. The reason for that is NHibernate not forcing you to choose a name convention to be compliant, NH will works with almost any naming convention.
There are cases where the properties are not suitable for NH to set values.
They may
have no setter at all
call validation on the data that is set, which is not used when loading from the database
do some other stuff that is only used when the value is changed by the business logic (eg. set other properties)
convert the value in some way, which would cause NH performing unnecessary updates.
Then you don't want NH to call the property setter. Instead of mapping the field, you still map the property, but tell NH to use the field when reading / writing the value. Roger has a good explanation why mapping the property is a good thing.
I am trying to build a generic solution to a problem that is probably much more complicated than I realize.
For simplicity, consider that I have the following interface:
PagedResult<T> ToPagedResult<T>(this ICriteria, criteria, string sortName);
sortName is ideally a json-style path of access. E.g : Registration.Class.Curriculum.Description, where description is the property that we want to sort on.
In the case where I want to sort on a property of Class, I have been successful with the following:
ICriteria pageCriteria = criteria.CreateCriteria("Class", "Class").AddOrder(Order.Desc(sortName));
In this case, sortName might equal "Class.Name".
Now, is there a way where I could arbitrarily allow sorting on deeper children?
ICriteria pageCriteria = criteria
.CreateCriteria("Class", "Class")
.CreateCriteria("Class.Foo", "Foo")
.AddOrder(Order.Desc("Foo.Bar"));
In a passport there is a field: First Name, and that field has a value John.
I assert that it is correct to describe the relationship as follows:
Field First Name:
Has a name (First Name).
Has a set of valid values (e.g. defined by regex [A-Za-z. ]{1,30}
Has a description (name that stands first in the person's full name)
And Passport is a set of pairs (field : field value), such that:
passport has a field "First Name"
passport has a value for field "First Name"
Point here is that it is incorrect to say:
"First Name value is John";
The correct way (conceptually/academically) is to say:
"passport has a value 'John' for field 'First Name'".
In practical terms it means (pseudo C#):
struct Passport {
Map<Field, object> fieldValues;
}
struct Field {
string Name;
string Description;
bool IsValidValue(object value);
}
Q: Does this make sense? Any thoughts?
This is pretty subjective and entirely context sensitive, and seems like a silly thing to nitpick over.
Correct or not, if I'm discussing "passport" with a co-worker, I'd throw something at them if they corrected me every time I said "firstName is 'john'", and told me to say it as "passport's firstname field is 'john'". You'd just come across as annoying.
Well..not really in c# see Scott Bellware's answer to my question about C# not being Object Oriented (kinda).
In C# passport is a class so it makes perfect sense to say
"The Passport has a field FirstName"
For a particular instance "FirstName value is John".
Here the first clause describes the class and the next one the object. In a more OO language like ruby I think saying "passport has a value 'John' for field 'First Name'" would be equivalent, you're just describing two objects - the Passport prototype, and the instance of it in the same sentence.
I'm getting pretty confused in it myself though. The question is oddly phrased since there would doubtless be much more to a passport than just its fields, for example a long-standing and persisted identity.
If you are going to model such thing, then you may take a look at reflection API of java or c#. It is pretty similar to what you described. Class has set of fields, field has name, type and other attributes, not value. Object is an instance of class and you can ask object for the value of specified field. Different objects of the same class have values for the same fields, so you may say they share fields. So if you are trying to model class-based OOP then you are probably right.
However this is not the only way to do OOP. There is prototype-based OOP which looks differently, as there are no classes, only objects, so objects contain field with values so there is not much difference if you say that object contain field and field has a value.
So the answer to "Does this make sense?" I think is "yes" because similar thing is in reflection and is used widely. If it is right or wrong - depends on your needs.
UPD: regarding "value = Passport[Field]" vs "value = Passport.Field.Value"
I'd introduce one more passport to make it clear
firstNameField = PassportClass.Fields["FirstName"]
myName = myPassport[firstNameField]
yourName = yourPassport[firstNameField]
assumes that both passport have same fields, that makes sense. Having different passports with different fields may have a sense, just a different one.
No. At least in OOP, it's the field's responsibility to retain the value. Although the object is responsible for ensuring that value is consistent with the other fields or the object's constraints, the actual "containing of the value is the field's job.
Using your example:
Field First Name:
Has a name (First Name).
Has a type (int, string, object)
Has a description (optional)
Has a value
And Passport is a set fields:
May define constraints on such a field as defined by the model, ensuring the value and the object's state as a whole is valid