Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Query stream issue #151 #152

Merged
merged 3 commits into from
Nov 27, 2020
Merged

Query stream issue #151 #152

merged 3 commits into from
Nov 27, 2020

Conversation

RTrackerDev
Copy link
Contributor

Minor fix for #151

@RTrackerDev
Copy link
Contributor Author

@greenrobot @Buggaboo @vaind could you check please?

Copy link
Collaborator

@vaind vaind left a comment

Choose a reason for hiding this comment

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

Looks reasonable to me though I'd be happier if @Buggaboo could have a quick look as an author of the code. Unfortunately, I'm not 100% confident with this section yet.

@vaind
Copy link
Collaborator

vaind commented Nov 23, 2020

And almost forgotten... is it possible to test this? Would a small test case to verify the issue was there before (and is not anymore after the changes) be too hard to do? That'd help make avoid future regressions.

@Buggaboo
Copy link
Contributor

Buggaboo commented Nov 24, 2020

test(
      'Only observers of a single entity are notified, no cross-entity observer notification',
      () async {
    // setup listeners
    final box2 = Box<TestEntity2>(env.store);

    var counter1 = 0, counter2 = 0;

    final query2 = box2.query().build();
    final queryStream2 = query2.findStream();
    final subscription2 = queryStream2.listen((_) {
      counter2++;
    });

    final query1 = box.query().build();
    final queryStream1 = query1.findStream();
    final subscription1 = queryStream1.listen((_) {
      counter1++;
    });

    // counter2 test #.1
    final t2 = TestEntity2();
    box2.put(t2);

    await Future.delayed(Duration(seconds: 0));
    expect(counter1, 0);
    expect(counter2, 1);

    // counter1 test #.1
    final t1 = TestEntity();
    box.put(t1);

    await Future.delayed(Duration(seconds: 0));
    expect(counter1, 1);
    expect(counter2, 1);

    // counter1 many test #.2
    final ts1 = [1, 2, 3].map((i) => TestEntity(tInt: i)).toList();
    box.putMany(ts1);

    await Future.delayed(Duration(seconds: 0));
    expect(counter1, 2);
    expect(counter2, 1);

    // counter2 many test #.2
    final ts2 = [1, 2, 3].map((i) => TestEntity2()).toList();
    box2.putMany(ts2);

    await Future.delayed(Duration(seconds: 0));
    expect(counter1, 2);
    expect(counter2, 2);

    query1.close();
    query2.close();

    await subscription1.cancel();
    await subscription2.cancel();
  });

  // TODO query.stream test

I'm looking into it.

@RTrackerDev
Copy link
Contributor Author

RTrackerDev commented Nov 24, 2020

And almost forgotten... is it possible to test this? Would a small test case to verify the issue was there before (and is not anymore after the changes) be too hard to do? That'd help make avoid future regressions.

@vaind I wanted to add tests but I have problems running on mac OS

@Buggaboo
Copy link
Contributor

Buggaboo commented Nov 24, 2020

Have you run 'install.sh'?

Also stripped the 'dart' exec?

@@ -9,7 +9,7 @@ import 'util.dart';
// ignore_for_file: non_constant_identifier_names

// dart callback signature
typedef Any = void Function(Pointer<Void>, Pointer<Uint32>, int);
Copy link
Contributor

@Buggaboo Buggaboo Nov 24, 2020

Choose a reason for hiding this comment

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

The change to the 2nd param is questionable.

It's an array of Uint32s.

The array should be unpacked, and the entityId it contains should be used to trigger the specific callback(s) indexed by storePtr and entityId. I might have been a bit sloppy.

Copy link
Contributor Author

@RTrackerDev RTrackerDev Nov 24, 2020

Choose a reason for hiding this comment

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

The change to the 2nd param is questionable.

It's an array of Uint32s.

The array should be unpacked, and the entityId it contains should be used to trigger the specific callback(s) indexed by storePtr and entityId. I might have been a bit sloppy.

@Buggaboo I didn't change it. Please look at the end result.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sure. I'm on it.

@RTrackerDev
Copy link
Contributor Author

Have you run 'install.sh'?

Also stripped the 'dart' exec?

install.sh ?

@RTrackerDev
Copy link
Contributor Author

Have you run 'install.sh'?

Also stripped the 'dart' exec?

Thank you i resolved it

@Buggaboo
Copy link
Contributor

Buggaboo commented Nov 24, 2020

I have this feeling the callback in C is not behaving the way it's documented.

Nope. Improper testing on my side.

@RTrackerDev
Copy link
Contributor Author

@vaind @Buggaboo I added unit test and resolve conflicts

@RTrackerDev
Copy link
Contributor Author

I have this feeling the callback in C is not behaving the way it's documented.

He is behaving correctly. The problem is that everyone subscribes to a single stream controller, which notifies everyone.

@RTrackerDev
Copy link
Contributor Author

RTrackerDev commented Nov 24, 2020

@Buggaboo In my opinion, the best solution is to move this StreamController as value to the Query and when the Query is closed, close the controller

@Buggaboo
Copy link
Contributor

@vaind Do we still have to close Queries? Or did I forgot to add them?

@Buggaboo
Copy link
Contributor

Buggaboo commented Nov 24, 2020

I found another (conceptual) bug. Fixing it.

The number of C callback notifications should not increase linearly along with the number of dart listeners. Only one C observer per store should be initialized to serve notifications.

@RTrackerDev
Copy link
Contributor Author

I found another (conceptual) bug. Fixing it.

The number of C callback notifications should not increase linearly along with the number of dart listeners. Only one C observer per store should be initialized to serve notifications.

@vaind @Buggaboo But this PR you could merge.

@Buggaboo
Copy link
Contributor

I took your changes with a fix for another bug I found. I have to redo it again because I based off the wrong branch.

@Buggaboo
Copy link
Contributor

I found another (conceptual) bug. Fixing it.
The number of C callback notifications should not increase linearly along with the number of dart listeners. Only one C observer per store should be initialized to serve notifications.

@vaind @Buggaboo But this PR you could merge.

I was looking at an old branch :(, that other problem was fixed already.

@RTrackerDev
Copy link
Contributor Author

I found another (conceptual) bug. Fixing it.
The number of C callback notifications should not increase linearly along with the number of dart listeners. Only one C observer per store should be initialized to serve notifications.

@vaind @Buggaboo But this PR you could merge.

I was looking at an old branch :(, that other problem was fixed already.

What problem was fixed?

@Buggaboo
Copy link
Contributor

I found another (conceptual) bug. Fixing it.
The number of C callback notifications should not increase linearly along with the number of dart listeners. Only one C observer per store should be initialized to serve notifications.

@vaind @Buggaboo But this PR you could merge.

I was looking at an old branch :(, that other problem was fixed already.

What problem was fixed?

Only one C observer per store should be initialized to serve notifications.

@Buggaboo
Copy link
Contributor

Buggaboo commented Nov 24, 2020

@vaind, I sent @RTrackerDev a PR with an extra test and a type check appeaser. Once that's merged to this branch, this one is ready to go.

Copy link
Contributor

@Buggaboo Buggaboo left a comment

Choose a reason for hiding this comment

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

My changes weren't really helpful. In hindsight. This is good to go.

@RTrackerDev
Copy link
Contributor Author

@vaind @Buggaboo Could you merge if its Ok?

@Buggaboo
Copy link
Contributor

@vaind could do it. I don't have the permissions. @RTrackerDev he's a busy guy. Regardless, your contribution is appreciated. (At least by me)

@vaind
Copy link
Collaborator

vaind commented Nov 27, 2020

thx for the fix @RTrackerDev and the support @Buggaboo, merging.

FYI there will be major changes to query streams implementation, to support asynchronous callbacks (across multiple isolates), see #145.

@vaind vaind merged commit 4faf387 into objectbox:main Nov 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants