joantune / maidsyncher Goto Github PK

PropertyUtils.isWriteable returns false - this is because it returns itself (flow style) instead of returning void. Either one corrects this, or copies the code by hand (hella lot boilerplate)

This happens sometimes while running syncher-web with mvn jetty:start and then running mvn exec:java -Dexec.mainClass="pt.ist.Main" in the syncher-main;

Talking with @jcarvalho, I got to know that this error only happens when an instance of a fenix-framework app that is sharing a database with another (which is the case) cannot load an instance because a class has disappeared/is unknown to that apps DML.

Thus, we think the culprit is the fact that the scheduler classes exist only in the syncher-web through the dependence that is explicitly declared in the syncher-web-restserver but not on the syncher-main

GHRepository:

• C
• U

GHMilestone:

• C
• U

GHIssue:

• C
• U

GHComment:

• C
• U

GHLabel:

• C
• U

ACProject:

• C
• U

ACMilestone:

• C
• U

ACTask:

• C
• U

ACSubTask:

• C
• U

ACComment:

• C
• U

ACLoggedTime:

• C
• U

Save the permalink and use that instead of the modified (for use with the API url).

in case we have the domain instances available. It makes it simpler

When creating the first sync, everything goes well. On the second time, this gets triggered:

18:55:08.743 [pt.ist.Main.main()] INFO pt.ist.maidSyncher.domain.MaidRoot - Running SyncActionWrapper for event: Sync event, DSIElement: 240518172181 (DSIIssue) Type: UPDATE targetUniverse: GITHUB originObject: ACTask Changed descriptors: updatedById body createdById categoryId

and it shouldn't

GHLabel(s) DSIObject might not exist (depending on the label name), there fore, because of the dependedOn and similar method of the SyncActionWrapper, it might be useful to add a field to the SyncEvent telling which class(es) of DSIObject a SyncEvent might create

if a sync of a DSIObject fails for some reason. Let's delete that 'empty' DSIObject, so that the next time the synching process runs, it detects the CREATE event again

GHOrganization:

• C
• U
• D

GHRepository:

• C
• U
• D - fails, create issue

GHMilestone:

• C
• U
• D - fails, create issue

GHIssue:

• C
• U

GHComment:

• C
• U
• D - fails, create issue

GHLabel:

• C
• U
• D

GHUser:

• C

• U

• D

  ACollab (inc.)

In the earlier tests (GHIssueSyncTests), there were incorrect uses of the mockito code. It shouldn't take long to correct those and use mockito as it was meant to be used.

When adding SyncEvent's to the changesBuzz, make sure that if the origin universe is equal, the apiObject of all of those events that may already exist for that given DSIObject, are the same, if they aren't, it means that that object meanwhile changed (between SyncEvent) generations, and the Sync needs to be redone. This way, we can avoid having less exceptions sent when applying the ChangesBuzz.

Alternatively, check this only when processing the ChangesBuzz (before any change is made)

Probably a good place is a popover of the 'Failure' word in the modal

If a sync action throws an error, keep it's SyncEvent on the queue to process, thus making sure that the sync occurs

So, basicly, make sure that all of the 'touched' objects are returned in the .sync() of the SyncAction, and that those are used to complete the SyncActionLog with more info, that in turn will be displayed in the web interface, so one has a feeling of which objects were changed by which action

i.e. show that it's ongoing (have a state ongoing [that is closed at the start of another sync in the case that ongoing sync was abruptly stopped]). When a sync is in that state, don't allow them to show the details view (it is the simplest support possible)

This is kinda of tricky because you would need an AC test instance to actually test the API (?) or do an elaborate Mock of it, that kinda would defeat the purpose (?). Anyway, I'm not sure what is the response, in case of edits, like:

• ACCategory - update method - what happens when one of the ids (project or category) is wrong. At least this would be useful to test

Related with #28
List of objects that usually are deleted:

GHMilestone
GHLabel
GHComment

Everything (?) on the AC Side

Output example:

Issue 1 name: test issue milestone: - labels: 21:45:19.076 [pt.ist.Main.main()] DEBUG p.i.m.domain.SynchableObject - Synching 12884902091 class: pt.ist.maidSyncher.domain.github.GHIssue changed properties: labels
duplicate invalid
got 4 comments. Showing them:
Comment 13442231 and a test comment
21:45:19.290 [pt.ist.Main.main()] DEBUG p.i.m.domain.SynchableObject - Synching 12884902091 class: pt.ist.maidSyncher.domain.github.GHIssue changed properties: labels
Comment 13442242 and things, more things @time 20m
21:45:19.298 [pt.ist.Main.main()] DEBUG p.i.m.domain.SynchableObject - Synching 12884902091 class: pt.ist.maidSyncher.domain.github.GHIssue changed properties: labels
Comment 13965715 aaand, another comment
21:45:19.306 [pt.ist.Main.main()] DEBUG p.i.m.domain.SynchableObject - Synching 12884902091 class: pt.ist.maidSyncher.domain.github.GHIssue changed properties: labels
Comment 14141904 added a comment, just to see it synching
21:45:19.313 [pt.ist.Main.main()] DEBUG p.i.m.domain.SynchableObject - Synching 12884902091 class: pt.ist.maidSyncher.domain.github.GHIssue changed properties: labels
List of members:
nullnulljoantune

Instead of the switch case, one could register smaller "SyncAction" instances that would take care of a given descriptor, and consume it.

In the end, if consumers where still present, a warning or error would be thrown (meaning we didn't take into consideration all of the changes). This would prevent the use of that nasty boilerplate switch case, which is half idiotic, but that hopefully does the trick of forcing you to take into consideration all of the changes.

Also, this would allow logs to be made, as one of the methods of the smaller SyncAction would be a description of what it did, e.g. the milestone descriptor changes on an ACTask, you would have a SyncAction that consumed that event and whose description of its actions would be something like, created/reused the corresponding milestone number/url on the GH side.

Anyway, this for now is a question for future processing, because the SyncAction might have more requirements that haven't been fully envisioned now (depending on the problems that will arise in the future). And also because there are some other issues to solve with this approach, like how to take care of the state that should be shared between SyncAction's e.g. a Issue that is to be edited/created on the GH side should be shared. It isn't clear yet on how this and other issues are going to be solved with this approach (and now the priority is to put this to work).