I do understand that Xodus' Entity Store provides StoreTransaction.find(..) which matches properties with the exact provided value and StoreTransaction.findStartingWith(..) which matches properties beginning with the provided value.
What I don't see is a StoreTransaction.findContains(..) or a LIKE of any sort. How would I approach such a search?
In version 1.3.232, there is no such. It makes sense to file a feature request.
Related
I was reading DWARFv4 spec and came across attribute DW_AT_endianity.
Correct me if my understanding is wrong.
As per spec, Two of the tag values TAG_variable and TAG_base_type both can have that attribute.
But as far as, i understand when you create a TAG_variable you have to pass the "Type", which can be of TAG_base_type(others are also possible).
So my question is if we are setting DW_AT_endianity on TAG_variable, why TAG_base_type also supports that attribute.
In other words every variable is of some type and can have that attribute, so why need attribute support for both type and variable?
The DW_AT_endianity attribute was the response to a proposed C compiler extension allowing the "creation of data in both big and little endian formats". It appears that the attribute was intended for base types (like this example) or structs/unions (like this one). Using the same attribute for both a simple variable and its underlying base type would, as you say, be redundant — note that the attribute is optional (see DWARF 4, sections 4.1.12 and 5.1).
My app uses CoreData framework and I want to check compatibility between a store metadata and a managed object model. I do it standard way:
BOOL isModelCompatible = [model isConfiguration:nil
compatibleWithStoreMetadata:metadata];
and it returns NO. However the entities in the metadata are the same as in the model. The same number of entities and each entity has the same name. However the model indeed has changed since the time the store was created using this model, I removed a couple of attributes in one entity. And I'm wondering if that is enough for a model to become incompatible with the store metadata. I took a look into the official documentation and it says:
This method compares the version information in the store metadata with the entity versions of a given configuration
And the problem (as it often happens when I read Apple's docs) is that I'm not quite sure what exactly this phrase means. So can anyone explain more regarding that topic? How CoreData decides if a model is compatible or not to a metadata given that enteties in the metadata are the same as in the model?
A model is incompatible with a persistent store any time there's a difference that affects how data is stored in the data file. Removing attributes would qualify, since that change would affect how data was saved in SQLite. Some changes don't lead to incompatibility-- for example, if you changed a relationship from optional to required-- because the data file would be the same either way.
If you want to get the exact details, look at the versionHash property of NSEntityDescription and related classes. That will tell you exactly what's used, and anything not mentioned doesn't affect compatibility. For example on NSEntityDescription it includes
The values which affect persistence are: the name of the entity, the version hash of the superentity (if present), if the entity is abstract, and all of the version hashes for the properties.
To continue from there, look up the same property on NSPropertyDescription and its subclasses.
Core Data's model migration gets past the incompatibility by updating the persistent store to match the new data model. Often this can be done automatically, as with lightweight migration. Removing attributes would allow lightweight migration.
(Data models renamed to preserve anonymity. :D )
So, I have a situation where on a Thing, whose configuration is defined by its own special object, though that object can be one of 2 class types.
I would like to be able to do Fetch Requests on this model by asking if the Thing's Configuration is of a certain known subclass, and if so, does it have a few specific flags set in its bitmask. If this is true, I define this as being "not special". Therefore, if it also has the other type of subclass as it's Configuration, it is also "not special".
My questions are these:
Have I got my syntax right? (In my app I get faults)
Why does it want to return an NSArray? (I thought its traversing a to-one relationship on a single object. How would I therefore interpret this NSArray?)
I should add that I only know Core Data via MagicalRecord more or less. And I use mogenerator too.
I understand that in MVC pattern and in REST services it is common to use URIs like /items/{id} but what is bad thing about using query parameters in the URI?
GET /items/{id} vs GET /items?id={id}
Further, lets say an entity has 'referenceId' field that points to some related (say parent) entity, and I need to create REST service to get all items for parent entity, which way is better:
GET(POST) /items/parent/{parentId}
or
GET(POST) /items?parent={parentId}
Will be grateful for insights that would help to resolve my subjective issues on constructing URLs for REST services.
I would use the following schemes.
/items/id
This uniquely addresses a resource of items with id id. We are not using parameters as a parameter to uniquely address this resource (as is the case with the other option). Just as
miguelcobain suggests.
/parent/id/items
Here id is an id to uniquely address a resource of parent and from those we collect/retrieve the items it references. From what you have said in the question it seems that parent references multiple items, like a container or collection.
The convention I use for this is to narrow down the scope going from left to right. Therefore in case items could be active or inactive. Thusly items have a property or attribute to be active or inactive. Narrowing down on this I get the following scheme:
/items/active
/parent/id/active
For your first question:
/items/{id} should retrieve a single resource with the specified id or 404 if it doesn't exist.
/items/?id={id} should retrieve an array (even if only one in the array) because you are querying the collection.
For your second question:
I agree with #miguelcobain's assessment - if the item is a specific resource/entity, just use the proper resource path to retrieve it.
To make this easier on the consumer, create a link header with rel="parent" and/or include the uri in the child resource. For an example of link headers, see GitHub's pagination api.
Of course, REST principles don't care about aesthetic details on URLs. It just imposes that every resource should be uniquely addressable.
Furthermore, using the query parameters to uniquely address something "kind of" violates the semantics of a "parameter", doesn't it? A parameter should be something optional, something additional and parameterized. Something like a detailed search on a collection of items, for example.
What you wrote may make sense in some cases. It depends.
In your example, is the item really a resource? If not, you could just do GET(POST) /parents/{parentId}.
If parent is, say, a boolean, and you want to search the items that have parent equals to true, then using the parameters makes sense. But since you're explicitly saying that you want a parent with a specific id, I assume that parent is a resource itself and I would uniquely address that resource using your option 1.
I hope I made myself clear.
It seems to me there are no rules to follow.
items/{id} - this convention is suitable for GET item by given id. If user doesn't provide id then it returns 404 status code.
items/id={id}&name={name} - this type of convention is suitable for search multiple items by given criteria. If no items are found, it is not a 404 situation, you simply say "I successfully found nothing matching your search criteria"
Is it possible to query an OData collection filtering by the updated metadata field? The case for that would be to get a list of updates since the last check.
I've tried http://odata.netflix.com/v1/Catalog/People?$filter=updated%20eq%202011-05-15T21:45:31Z, but it gives me "No property 'updated' exists in type 'Netflix.Catalog.Person' at position 0". Is there another way I can do this or reference the updated property in a filter statement?
The updated element in the ATOM feed/entry representation may or may not contain actual data. Some services actually do store the real updated timestamp there, but some don't. Since the element is required to be present in all entries by the ATOM format, services which don't have the data to use there usually put some arbitrary timestamp as the value (by default WCF Data Services uses DateTime.Now for the updated field, which is what netflix service does as well).
The $filter can only reference real properties on a given entity. So if the service does have a property which contains the data backing the updated element you would need to find out the name of such property (in the $metadata for example) and then use that. If the service does not have a property like that (for example the netflix service doesn't), then there's no way to filter based on last updated timestamp, as there's no such thing in the underlying data store (the updated element is effectively a fake).
Also note that if you ask for JSON payload the updated element doesn't exist there and so only the real properties are present. Any query operators in the URL work only on the real properties.