Skip to content

Events Map JPA implementation#12233

Merged
hmlnarik merged 1 commit intokeycloak:mainfrom
sguilhen:9667-events-jpa-store
Jun 21, 2022
Merged

Events Map JPA implementation#12233
hmlnarik merged 1 commit intokeycloak:mainfrom
sguilhen:9667-events-jpa-store

Conversation

@sguilhen
Copy link
Copy Markdown
Contributor

Closes #9667

@sguilhen sguilhen requested a review from vramik May 27, 2022 23:13
@sguilhen sguilhen added area/storage Indicates an issue that touches storage (change in data layout or data manipulation) team/storage-sig labels May 27, 2022
@sguilhen sguilhen force-pushed the 9667-events-jpa-store branch 4 times, most recently from 6144978 to 9543526 Compare May 29, 2022 02:37
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vramik I've borrowed the above code from your authz PR. Once that is merged I'll update.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: should the expiration be part of this index? It is used on every query to avoid returning expired entities.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable to me, will remove it from the index.

Copy link
Copy Markdown
Contributor Author

@sguilhen sguilhen May 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for only having fk_root index

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed, both event entities no longer have a delegate.

@sguilhen sguilhen force-pushed the 9667-events-jpa-store branch 4 times, most recently from c38877b to 9467c46 Compare June 8, 2022 15:20
Copy link
Copy Markdown
Contributor

@vramik vramik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @sguilhen for the PR! I've done first round of review and have some comments, please see inline. I'll take another look once #12299 is merged.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't you mean?

Suggested change
private static final Map<String, String> FIELD_TO_JASON_PROP = new HashMap<>();
private static final Map<String, String> FIELD_TO_JSON_PROP = new HashMap<>();

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes, definitely.. nice catch!

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dtto

Suggested change
private static final Map<String, String> FIELD_TO_JASON_PROP = new HashMap<>();
private static final Map<String, String> FIELD_TO_JSON_PROP = new HashMap<>();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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))

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, will revert this change.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

out of curiosity: why this change?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for only having fk_root index

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@sguilhen sguilhen force-pushed the 9667-events-jpa-store branch from 9467c46 to 5e02672 Compare June 8, 2022 18:13
@sguilhen sguilhen requested a review from vramik June 10, 2022 12:00
@sguilhen sguilhen force-pushed the 9667-events-jpa-store branch from 5e02672 to 278871d Compare June 10, 2022 13:20
Comment on lines 889 to 890
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please use a different separator than . for eventsStore.admin, e.g. eventsStore-admin or (perhaps better) even adminEventsStore?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

@sguilhen sguilhen force-pushed the 9667-events-jpa-store branch 2 times, most recently from c3240ba to 57dd4b4 Compare June 17, 2022 13:45
vramik
vramik previously approved these changes Jun 20, 2022
Copy link
Copy Markdown
Contributor

@vramik vramik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you @sguilhen!

Depending whether #12230 will be merged first, this one will require rebase due to the EXPIRATION removal.

@hmlnarik
Copy link
Copy Markdown
Contributor

@sguilhen #12230 is merged, could you please rebase?

@sguilhen
Copy link
Copy Markdown
Contributor Author

@hmlnarik Rebased!

@hmlnarik hmlnarik requested a review from vramik June 20, 2022 20:50
Copy link
Copy Markdown
Contributor

@vramik vramik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @sguilhen, great work!

Copy link
Copy Markdown
Contributor

@vramik vramik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

@vramik
Copy link
Copy Markdown
Contributor

vramik commented Jun 21, 2022

@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?

@sguilhen
Copy link
Copy Markdown
Contributor Author

@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 JpaMapKeycloakTransaction for all expirable entities, so the criteria builders for each area don't have to append expiration criteria to every query.

Copy link
Copy Markdown
Contributor

@hmlnarik hmlnarik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving per @vramik 's review

@hmlnarik hmlnarik merged commit 7d96f3a into keycloak:main Jun 21, 2022
@sguilhen sguilhen deleted the 9667-events-jpa-store branch October 19, 2022 14:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/storage Indicates an issue that touches storage (change in data layout or data manipulation)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

JPA map storage: Events no-downtime store

3 participants