Create documents in CMIS - java

Could you tell me if there is any possibility to create documents which parent would be another document.
ObjectId parentId = session.createObjectId(someDocumentStringId);
session.createDocument(properties, parentId, stream, VersioningState.None);
Now I get error: Operation not supported by the repository for this object!

Documents are not containers in CMIS. Only a folder can be a parent of a document.
Have a look at CMIS relationships. They may solve your problem.

Related

Netflix DGS: Throw Exception if DataLoader fails to received data for all objects

I'm using Netflix DGS library in SpringBoot, and I have a parent query that whose schema is something like,
type Parent #connection {
attr1
attr2
...
child1: Child
}
type Child {
childAttr1
childAttr2
Here for a graphql query to fetch first 10 records for Parent, I'm using Data Loader to load all the Child data at once for all the 10 Parents using.
Currently bulk fetch for Child returns a List which may or may not contain values for every Parent object. I want to add a error block which can be attached to the request to notify which Parent object didn't had Child.
Since the Data Loader returns a CompletableFuture, I am not able to interrupt the flow and throw an exception if data is null.
Is there some solution to this problem, or any other way with which it can be handled?
Thanks!

Lucene document structure to correctly group a collection of keys

I have a Java model like this (some fields omitted):
#Searchable(root=true)
class Person {
#SearchableProperty
String sex;
#SearchableProperty
String name;
}
class Parent extends Person {
#SearchableComponent
List<Person> children;
}
This model creates a lucene document with the following data for person Anakin:
$/person/sex:male
$/person/name:anakin
$/person/children/sex:male
$/person/children/name:luke
$/person/children/sex:female
$/person/children/name:leia
Assuming this is only one of many documents, I can search like this:
Find persons with a name starting with an and has a male child
$/person/name:an* AND $/person/children/sex:male
Find persons with a male child and a female child
$/person/children/sex:male AND $/person/children/sex:female
I run into trouble when trying to find a child with a specific name and sex, like this
$/person/children/sex:male AND $/person/children/name:leia
This will return a result, and I can see why. I would like this to return no results. My question is how can I discriminate or associate these nested properties such that my queries return valid data?
I have considered:
Storing the children as separate documents, though by doing this I lose the ability to search in the way I have written above.
Using an id field somehow in the query to group these fields. I haven't been able to come up with a way which is 'right'. Variants I have considered:
$/person/children/1/name:luke
$/person/children/name:luke1 or $/person/children/name:1luke
I'm not familiar with Compass, but on the Lucene level you can use BlockJoinQuery to nest the child documents into your parent document and query them.
Mike McCandless has an excellent blog post on using BlockJoinQuery in Lucene 3.4 [1]. That should give you the basic concepts. However in Lucene 4 the API has changed and is now under the org.apache.search.lucene.join package. There is a code example in the Javadoc [2].
[1] http://blog.mikemccandless.com/2012/01/searching-relational-content-with.html
[2] http://lucene.apache.org/core/4_10_1/join/org/apache/lucene/search/join/package-summary.html

Store Parent/Child in a Batch Put on Appengine with Objectify

I'd like to store 2 new entities in a batch put. However, one entity is the parent of the other. If I have a a field in the child object that looks like:
#Parent
private Key parent
How do I fill in a value for this field in the child object if the parent hasn't been stored yet (and thus has no key yet).
Allocate the id of the parent in advance. Then you can save the parent and the child (with a parent key reference) in a single batch put.
Yo can not do it that way (as one batch).
If your question is more concerned with data integrity, then you may use transactions.
Example:
from google.appengine.ext import db
from app.models import ParentModel, ChildModel
class ARequestHandler(BaseHandler):
def get(self):
def create_parent_and_child():
parent_entity = ParentModel(...)
parent_entity.put()
child_entity = ChildModel(Parent=parent_entity, ...)
child_entity.put()
db.run_in_transaction(create_parent_and_child)

JPA2(JBoss7.1's Hibernate) entityManager.find() is getting data from Cache not from DB

I am developing a web application using JSF2, JPA2, EJB3 via JBoss7.1.
I have an Entity(Forum) which contains a list of child entities(Topic).
When I tried to get the list of Topics by forumId for the first time the data is being loaded from DB.
List<Topic> topics = entityManager.find(Forum.class, 1).getTopics();
After that I am adding few more child entities(Topics) to Forum and then again I am trying to retrieve list of Topics by forumId. Nut I am getting the old cached results only. The newly inserted child records are not being loaded from DB.
I am able to load the child entities(Topics) by using following methods:
Method1: Calling entityManager.clear() before entityManager.find()
Method2: Using
em.createQuery("select t from Topic t where t.forum.forumId=?1", Topic.class);
or
em.createQuery("SELECT t FROM Topic t JOIN t.forum f WHERE f.forumId = ?1", Topic.class);
I am aware of setting the QueryHints on NamedQueries. But em.find() method is in a super CrudService which is being extended by all DAOs(Stateless EJBs). So setting QueryHints won't work for me.
So I want to know how can i make em.find() method to load data from DB instead of Cache?
PS: I am using Extended Persistence Context type.
#PersistenceContext(unitName="forum", type=PersistenceContextType.EXTENDED)
protected EntityManager em;
You can specify the behavior of individual find operations by setting additional properties that control the entity managers interaction with the second level cache.
Map<String, Object> props = new HashMap<String, Object>();
props.put("javax.persistence.cache.retrieveMode", CacheRetrieveMode.BYPASS);
entityMgr.find(Forum.class, 1, props).getTopics();
Is it possible that the relation between Forum and Topic was only added in one direction in your entity beans? If you set the forum id on the topic, you should also add this topic to the Forum object to have consistent data inside the first level cache. You should also make sure that you are not using two different entity managers for the update and find. The first level cache is only kept per entity manager, another em can still contain an older version of the entitiy.
Probably unrelated, but with JPA2 you also have a minimal api to evict entities from the second level cache, which could be used after an update:
em.getEntityManagerFactory().getCache().evict(Forum.class, forumId);
Put #Cacheable(false) within the Forum.class.

GWT Requestfactory entity locator does not work with Objectify when the Entity has Long id

My GWT+GAE app uses Requestfactroy entity locator and at the server side i use Objectify, it works well when my Entity ID type is String, now i want to change to Long id, and stuck: by using the locator signature i can not find the entity:
#Override
public T find( Class<? extends T> clazz, Long id )
{
}
Because Objectify requires #Parent key included to fetch the sub-entities(HRD), and from the method above we can not get the parent.
I found this thread from GWT forum:
here
However this thread seems didn't give any constructive suggestions(it falls back to String ID Entity finally for the solution).
Many thanks.
The problem is that the long ID is not enough to identify your object. As you say, you also need its parent, so the ID is actually a compound ID: the parent object, and the child's ID.
BTW, what's the problem with using the keyToString or similar here? (as suggested on the thread you link to)
The ID from a Locator is only used on the server-side and only by the locator (and serialized as-is to be passed back and forth to/from the client; but they're opaque things on the client-side, that you aren't even given access).

Categories