Bug 41343 – ucsschool-import: only execute modify() if user has actually changed

Bug 41343 - ucsschool-import: only execute modify() if user has actually changed


Summary:	ucsschool-import: only execute modify() if user has actually changed

Status:	RESOLVED WONTFIX

Product:	UCS@school
Classification:	Unclassified
Component:	Import scripts
Version:	unspecified
Hardware:	Other Linux

Importance:	P5 normal (vote)
Target Milestone:	UCS@school 4.1.x
Assigned To:	UCS@school maintainers
QA Contact:

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2016-05-25 16:14 CEST by Daniel Tröder
Modified:	2019-02-05 21:16 CET (History)
CC List:	3 users (show)

See Also:
What kind of report is it?:	Bug Report
What type of bug is this?:	1: Cosmetic issue or missing function but workaround exists
Who will be affected by this bug?:	5: Will affect all installed domains
How will those affected feel about the bug?:	1: Nuisance – not a big deal but noticeable
User Pain:	0.029
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):	UCS Performance
Max CVSS v3 score:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Daniel Tröder

2016-05-25 16:14:58 CEST

save LDAP operations

Comment 1 Daniel Tröder

2016-05-25 16:29:16 CEST

Modify() is an expensive operation. As the user object has already been open()ed, comparing its attributes is cheap and possibly saving a modify() operation worth it.

Comment 2 Daniel Tröder

2016-05-25 16:35:29 CEST

IMHO this should be done in ucsschool.lib.models.base.UCSSchoolHelperAbstractClass in a way that subclasses can extend it.

AFAIK UDM does this already. I have not really debugged it, just noticed that the modifyTimestamp changed on a user that was imported a 2nd time without any change to its attributes. I will look further into it later.

Comment 3 Sönke Schwardt-Krummrich

2016-05-26 11:17:48 CEST

Is this critical for the UCS@school 4.1R2 release? Otherwise we should change the behavior if it gets a problem later on.

Comment 4 Daniel Tröder

2016-05-26 12:58:07 CEST

I haven't really looked into it, but if it were like this, than IMHO it could be critical: if there is nothing to change, LDAP should not be bothered to do a modify() and hooks should not be executed.

A daily export with 99% unchanged users, but 100% running hooks should have a high impact.

Comment 5 Daniel Tröder

2016-06-06 15:00:35 CEST

Not a blocker for Bug #41239 anymore. Will be addressed after 4.1r2 release.

Comment 6 Florian Best

2016-10-04 12:53:22 CEST

UDM's handling should already be such intelligent.
This might also be enhanced/fixed by the patch at Bug #42513 because after this only 1 modify() call is done.

Comment 7 Sönke Schwardt-Krummrich

2019-02-05 21:16:28 CET

This issue has been filled against UCS@school 4.1 (R2). The maintenance with bug 
and security fixes for UCS@school 4.1 (R2) has ended on 5th of April 2018.

Customers still on UCS 4.1 are encouraged to update to UCS 4.3 (or later). 
Please contact your partner or Univention for any questions.

If this issue still occurs in newer UCS versions, please use "Clone this bug"
or simply reopen the issue. In this case please provide detailed information on
how this issue is affecting you.