Is it possible to clear the current watermark in a DataStream?
Example input for a month-long watermark with no allowed lateness:
[
{ timestamp: '10/2018' },
{ timestamp: '11/2018' },
{ timestamp: '11/2018', clearState: true },
{ timestamp: '9/2018' }
]
Normally, the '9/2018' record would be thrown out as it is late. Is there a way to programmatically reset the watermark state when the clearState message is seen?
Watermarks are not supposed to go backwards -- it's undefined what will happen, and in practice it's a bad idea. There are, however, various ways to accommodate late data.
If you are using the window API, Flink will clear any window state once the allowed lateness has expired for a window. If you want more control than this, consider using a ProcessFunction, which will allow/require you to manage state (and timers) explicitly.
Related
I have problem with ngrx simplest start up. Probably missing something
Isn' t it enough for devtools to display inital state list: [] ??
I have this
To view your store in the Redux-Devtools, you have to set up the StoreDevtoolsModule like described in the NgRx documentation
StoreDevtoolsModule.instrument({
maxAge: 25, // Retains last 25 states
logOnly: environment.production, // Restrict extension to log-only mode
autoPause: true, // Pauses recording actions and state changes when the extension window is not open
}),
When we create an event using google calendar API, it would not return hangout link in some cases, but return the status as pending.
"conferenceData": {
"createRequest": {
"requestId": "kavprurmn7h34jxcq6vgiufs2k",
"conferenceSolutionKey": {
"type": "hangoutsMeet"
},
"status": {
"statusCode": "pending"
}
}
},
I would assume that Google would return the Hangout link if we try to get the event after some time. The challenge is how to test this scenario. It is hard to reproduce this issue when you need to test, but the issue happens once in a while in production. How do we test this ? Is there a way to simulate this API behavior?
If the event is still pending not all information might be available. You have to try to get it until the event status is success.
In this situation you should use exponential backoff to try to get the Hangouts link. This prevents making unnecessary calls that may fill your quota or throttle your network. To accomplish this on Javascript, as an example, you can use .setTimeout(). Feel free to ask any question to expand this answer.
While making a game, I had set it up so when the player dies, the game resets. Feeling this was a bit too harsh, I did some research and found the room_restart() code, which is meant to restart the current room. But, when I input it and triggered it via dying, it did not reset the room to how it was. How do I reset it?
{
room_restart()
}
That is the code that triggers on collision with an enemy.
You would have to record the state somehow. Game Maker has a native state save function, but if you wanted a room to stay the same without changing the player's inventory or something, you'd have to manually record the state of every object in it so when the player leaves and comes back, everything resumes where it was.
You could try having each object record important variables to a file with sections for each room. For instance, you could use a JSON file with sections for each room, and each object would record their vital data into that section. For example:
{
"rmHouse": {
"Mom": {
"x": 64,
"y": 128,
"action": "lookingDown"
}
}
}
Check around for Game Maker JSON extensions. Here's one for GM8.1/Studio: http://gmc.yoyogames.com/index.php?showtopic=565659
room_goto(room);
That will send the room back to how it was when you first entered it, but room_restart should do the same.
Make sure that you do not have "persistent" checked in the room options. That's what sounds like it's probably the issue to me.
If you had
if(health = 0) {
instance_destroy();
}, then delete instance_destroy. Replace it with x = 32
y = 64
health = max_hp
restart_room();
so that the X position is set, the Y position is set, the health is back, and the room restarts.
I am using Meteor 0.8.2 with accounts-facebook. I set up a limited publication for the users this way:
Meteor.publish('users', function () {
return Meteor.users.find({}, {fields: {'profile.picture': 1, 'profile.gender':1, 'profile.type':1}, sort: {'profile.likes': -1}});
});
Now this works great: when I requests a user list from the client I get a list of all users, with the current user's fields all shown and only the 3 published fields for the others. Except: right after login.
When I login and type Meteor.user(), here is what I get:
_id: "uACx6sTiHSc4j4khk"
profile: Object { gender="male", type="1", picture="http://....jpg"}
This stays like that until I refresh the page using the browser button. After refreshing, Meteor.user() gives all the fields available, while Meteor.users.find() still gives the correct restrictions. (except for the current user of course)
Why does my current user not get all its fields right away? I read about a Meteor.userLoaded() method used to wait for the user to be loaded, but it seems to be obsolete in the latest version.
You're running into an interaction between the restriction of merging fields across publications, and the default user publication which sends the profile field.
First, note that there is a built-in publication that always sends the currently logged in user's entire profile field to that user:
https://github.com/meteor/meteor/blob/devel/packages/accounts-base/accounts_server.js#L1172
Second, merging of fields at more than one level deep is currently not supported:
https://github.com/meteor/meteor/issues/998
What you currently have is an issue where the default publication is sending something like the following
{
username: ...,
emails: [ ... ],
profile: {
... all fields ...
}
}
whereas the publication you have set up is sending
{
profile: {
picture: ...
gender: ...
type: ...
}
}
These get merged on the client according to the rules for how subscriptions are resolved (http://docs.meteor.com/#meteor_subscribe). In particular, see the last paragraph. Meteor knows to merge the username and email fields with the profile field. However, it doesn't do this merging at the inner level. So one of the profile fields will get chosen arbitrarily to show up in the client's collection. If the first one wins, you will see profile.likes. If the second one wins, you won't.
It's likely that this behavior is somewhat deterministic and changes depending on whether a normal login handler is called or a resume handler (i.e. when reloading the browser). Hence why it looks like it hasn't loaded.
As Andrew explained, and as I kinda thought, what happened is that there is another "hidden" publication for the current user, which conflicts with mine. All I had to do in order to fix this was to simply exclude the current user from my publication, since it is already fully published by default:
Meteor.publish('users', function () {
return Meteor.users.find({_id:{$ne: this.userId}}, {fields: {'profile.picture': 1, 'profile.gender':1, 'profile.type':1}, sort: {'profile.likes': -1}});
});
This simple $ne does it for me.
I am using Meteor 4.2 (Windows) and I am always getting the "update failed: 403 -- Access denied. Can't replace document in restricted collection" when I am trying to update an object in my collection. Strangely I had no problem inserting new ones, only updates are failing.
I tried to "allow" everything on my collection:
Maps.allow({
insert: function () { return true; },
update: function () { return true; },
remove: function () { return true; },
fetch: function () { return true; }
});
But still, this update fails:
Maps.update({
_id: Session.get('current_map')
}, {
name: $('#newMapName').val()
});
Is there something else I can check? Or maybe my code is wrong? Last time I played with my project was with a previous version of Meteor (< 4.0).
Thanks for your help.
PS: Just for information, when I do this update, the local collection is updated, I can see the changes in the UI. Then very quickly it is reverted along with the error message, as the changes has been rejected by the server-side.
Alright, the syntax was actually incorrect. I don't understand really why as it was working well before, but anyway, here is the code that works fine:
Maps.update({
Session.get('current_map')
}, {
$set: {
name: $('#newMapName').val()
}
});
It seems like it must be related to what you're storing in the 'current_map' session variable. If it's a db object, then it probably looks like {_id:<mongo id here>} which would make the update finder work properly.
I ran into the same issues, and found the following to work
Blocks.update {_id:block_id}, {$set: params}
where params is a hash of all the bits i'd like to update and block_id is the mongo object id of the Block i'm trying to update.
Your note about the client side update (which flashes the update and then reverts) is expected behavior. If you check out their docs under the Data and Security section:
Meteor has a cute trick, though. When a client issues a write to the server, it also updates its local cache immediately, without waiting for the server's response. This means the screen will redraw right away. If the server accepted the update — what ought to happen most of the time in a properly behaving client — then the client got a jump on the change and didn't have to wait for the round trip to update its own screen. If the server rejects the change, Meteor patches up the client's cache with the server's result.