Events Map JPA implementation#12233
Conversation
6144978 to
9543526
Compare
There was a problem hiding this comment.
@vramik I've borrowed the above code from your authz PR. Once that is merged I'll update.
There was a problem hiding this comment.
Question: should the expiration be part of this index? It is used on every query to avoid returning expired entities.
There was a problem hiding this comment.
Not sure to be honest. It might make sense to have it due to being part of each search as you said. On the other hand expiration field would be changed very often which would mean the need for re-calculating the index very often.
I'd go without it for now as database should be able to uset currently existing index and then "just" filter non-expired objects. And if it turns out the index is needed it can be added later, wdyt?
There was a problem hiding this comment.
Seems reasonable to me, will remove it from the index.
There was a problem hiding this comment.
Question: This is similar to the attributes tables we have for other entities, and those have an index for the name/value. I haven´t added such index here because the details are never queried by name or value, they are always loaded in their entirety, so to me only the fk_root index should be enough. Thoughts?
There was a problem hiding this comment.
+1 for only having fk_root index
There was a problem hiding this comment.
@vramik I've added the delegate for now, although we might decide to simply load everything - including the metadata - in read with parameters. You mentioned you would follow this approach for the user sessions, and if you do I'll update this one to be consistent with what you are doing there.
There was a problem hiding this comment.
Changed, both event entities no longer have a delegate.
c38877b to
9467c46
Compare
There was a problem hiding this comment.
Didn't you mean?
| private static final Map<String, String> FIELD_TO_JASON_PROP = new HashMap<>(); | |
| private static final Map<String, String> FIELD_TO_JSON_PROP = new HashMap<>(); |
There was a problem hiding this comment.
Ah yes, definitely.. nice catch!
There was a problem hiding this comment.
dtto
| private static final Map<String, String> FIELD_TO_JASON_PROP = new HashMap<>(); | |
| private static final Map<String, String> FIELD_TO_JSON_PROP = new HashMap<>(); |
There was a problem hiding this comment.
I believe we shouldn't transform ResouceType to String at this level, the searchable field states that it expects ResourceType.class as a filed type. I'd suggest rather change MapFiledsPredicates class as mentioned in #12299 (comment) but fist we should decide how the search should behave for ResourceType.CUSTOM (#12299 (comment))
There was a problem hiding this comment.
Agreed, will revert this change.
There was a problem hiding this comment.
out of curiosity: why this change?
There was a problem hiding this comment.
In the first version I've pushed I had it as a stream to be able to map it to String, but I've reverted that change and this is something that wasn't properly reverted. Will change it.
There was a problem hiding this comment.
+1 for only having fk_root index
There was a problem hiding this comment.
Not sure to be honest. It might make sense to have it due to being part of each search as you said. On the other hand expiration field would be changed very often which would mean the need for re-calculating the index very often.
I'd go without it for now as database should be able to uset currently existing index and then "just" filter non-expired objects. And if it turns out the index is needed it can be added later, wdyt?
9467c46 to
5e02672
Compare
5e02672 to
278871d
Compare
There was a problem hiding this comment.
Could you please use a different separator than . for eventsStore.admin, e.g. eventsStore-admin or (perhaps better) even adminEventsStore?
c3240ba to
57dd4b4
Compare
57dd4b4 to
5569262
Compare
|
@hmlnarik Rebased! |
There was a problem hiding this comment.
@sguilhen one question popped up - I assumed we should filter expired entities on the database level, but I cannot see where it is done. I can see expired entities are handled on model level within MapEventStoreProvider, but that way we'd load all entities from database. Did I got it wrong?
I've just seen #12623. Just to be sure, we'd tackle this within that issue? |
Yes, that's correct. Idea is to handle this in |
Closes #9667