Mixing
Platform Event ReplayId - metadata says it is a String of length 1000 but evidence shows it as an integer
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
4
down vote
favorite
Related post on uniqueness of replayIds
Using Workbench to examine metadata for the OOTB field ReplayId on any Platform Event SObject (one that ends in __e) shows:
- bytelength: 3000
- length: 1000
- type: String
Now, evidence shows (and Platform Event documentation and related StreamingAPI documentation) this value to be an integer. Even the JSON example in the StreamingAPI shows it as a number:
"clientId":"a1ps4wpe52qytvcvbsko09tapc",
"data":
"event":
"createdDate":"2016-03-29T19:05:28.334Z",
"replayId":55
,
"payload":"This is a message."
,
"channel":"/u/TestStreaming"
Further cementing the evidence that Replayid is an integer, doing a metadata describe on EventBusSubcriber, the fields Tip and Position are both of type int with 9 digit precision. These two fields define the relative points in the stream between last event published versus last event consumed.
So, should I care? Or is an assumption of integers good enough?
Rationale for asking ...
I was planning on a solution wherein I backed up incoming platform events to Sobjects by publishing out another platform event (which is guaranteed to publish even if the initial consuming transaction blows up on a Limits exception). Think of this a fallback backup solution.
The backup SObject had a uniquekey defined as the concatenation of the initial xxx__e sobjectType + Replayid. This strategy works fine if replayids are numbers as the unique key will be < 255 chars in length. But if Replayids can be 1000 characters long, I need to rethink things.
Side note ..to date in our org, Replayids have incremented up to about 1,000,000 for the most active xxx__e platform events
platform-event
asked 3 hours ago
cropredy
34.4k439117
add a comment |Â
up vote
4
down vote
favorite
Related post on uniqueness of replayIds
Using Workbench to examine metadata for the OOTB field ReplayId on any Platform Event SObject (one that ends in __e) shows:
- bytelength: 3000
- length: 1000
- type: String
Now, evidence shows (and Platform Event documentation and related StreamingAPI documentation) this value to be an integer. Even the JSON example in the StreamingAPI shows it as a number:
"clientId":"a1ps4wpe52qytvcvbsko09tapc",
"data":
"event":
"createdDate":"2016-03-29T19:05:28.334Z",
"replayId":55
,
"payload":"This is a message."
,
"channel":"/u/TestStreaming"
Further cementing the evidence that Replayid is an integer, doing a metadata describe on EventBusSubcriber, the fields Tip and Position are both of type int with 9 digit precision. These two fields define the relative points in the stream between last event published versus last event consumed.
So, should I care? Or is an assumption of integers good enough?
Rationale for asking ...
I was planning on a solution wherein I backed up incoming platform events to Sobjects by publishing out another platform event (which is guaranteed to publish even if the initial consuming transaction blows up on a Limits exception). Think of this a fallback backup solution.
The backup SObject had a uniquekey defined as the concatenation of the initial xxx__e sobjectType + Replayid. This strategy works fine if replayids are numbers as the unique key will be < 255 chars in length. But if Replayids can be 1000 characters long, I need to rethink things.
Side note ..to date in our org, Replayids have incremented up to about 1,000,000 for the most active xxx__e platform events
platform-event
asked 3 hours ago
cropredy
34.4k439117
add a comment |Â
up vote
4
down vote
favorite
up vote
4
down vote
favorite
Related post on uniqueness of replayIds
Using Workbench to examine metadata for the OOTB field ReplayId on any Platform Event SObject (one that ends in __e) shows:
- bytelength: 3000
- length: 1000
- type: String
Now, evidence shows (and Platform Event documentation and related StreamingAPI documentation) this value to be an integer. Even the JSON example in the StreamingAPI shows it as a number:
"clientId":"a1ps4wpe52qytvcvbsko09tapc",
"data":
"event":
"createdDate":"2016-03-29T19:05:28.334Z",
"replayId":55
,
"payload":"This is a message."
,
"channel":"/u/TestStreaming"
Further cementing the evidence that Replayid is an integer, doing a metadata describe on EventBusSubcriber, the fields Tip and Position are both of type int with 9 digit precision. These two fields define the relative points in the stream between last event published versus last event consumed.
So, should I care? Or is an assumption of integers good enough?
Rationale for asking ...
I was planning on a solution wherein I backed up incoming platform events to Sobjects by publishing out another platform event (which is guaranteed to publish even if the initial consuming transaction blows up on a Limits exception). Think of this a fallback backup solution.
The backup SObject had a uniquekey defined as the concatenation of the initial xxx__e sobjectType + Replayid. This strategy works fine if replayids are numbers as the unique key will be < 255 chars in length. But if Replayids can be 1000 characters long, I need to rethink things.
Side note ..to date in our org, Replayids have incremented up to about 1,000,000 for the most active xxx__e platform events
platform-event
asked 3 hours ago
cropredy
34.4k439117
Related post on uniqueness of replayIds
Using Workbench to examine metadata for the OOTB field ReplayId on any Platform Event SObject (one that ends in __e) shows:
- bytelength: 3000
- length: 1000
- type: String
Now, evidence shows (and Platform Event documentation and related StreamingAPI documentation) this value to be an integer. Even the JSON example in the StreamingAPI shows it as a number:
"clientId":"a1ps4wpe52qytvcvbsko09tapc",
"data":
"event":
"createdDate":"2016-03-29T19:05:28.334Z",
"replayId":55
,
"payload":"This is a message."
,
"channel":"/u/TestStreaming"
Further cementing the evidence that Replayid is an integer, doing a metadata describe on EventBusSubcriber, the fields Tip and Position are both of type int with 9 digit precision. These two fields define the relative points in the stream between last event published versus last event consumed.
So, should I care? Or is an assumption of integers good enough?
Rationale for asking ...
I was planning on a solution wherein I backed up incoming platform events to Sobjects by publishing out another platform event (which is guaranteed to publish even if the initial consuming transaction blows up on a Limits exception). Think of this a fallback backup solution.
The backup SObject had a uniquekey defined as the concatenation of the initial xxx__e sobjectType + Replayid. This strategy works fine if replayids are numbers as the unique key will be < 255 chars in length. But if Replayids can be 1000 characters long, I need to rethink things.
Side note ..to date in our org, Replayids have incremented up to about 1,000,000 for the most active xxx__e platform events
platform-event
platform-event
asked 3 hours ago
cropredy
34.4k439117
asked 3 hours ago
cropredy
34.4k439117
asked 3 hours ago
cropredy
34.4k439117
asked 3 hours ago
cropredy
34.4k439117
asked 3 hours ago
cropredy
34.4k439117
34.4k439117
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
3
down vote
So, should I care? Or is an assumption of integers good enough?
In my opinion, as long as it's documented to be numeric, I would go ahead and utilize this as number.
While this is still not clear why the describe would show a different result, but in any case if there's a scenario where there seems to be a discrepancy, I would reach out to Salesforce to make sure the implementation based on documentation will not fail.
Thinking it from a different perspective, if I use a Java Client using CometD to subscribe to an Event, I will always pass an numeric replayId instead of a String value to make sure that I successfully retrieve all replay ids after the value that I am passing.
answered 2 hours ago
Jayant Das
8,8552522
1
Jayant -- The CometD evidence was pretty convincing to me to stick with current plan; will let this marinate a bit to see what other responses come through.
– cropredy
2 hours ago
I am still baffled why does the describe on the field show it as string (I verified it myself). Will see if I can reach out to Salesforce support.
– Jayant Das
2 hours ago
@JayantDas Yes, I'd suggest contacting support. Bugs like this have happened before, and they usually get it fixed.
– sfdcfox
2 hours ago
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
So, should I care? Or is an assumption of integers good enough?
In my opinion, as long as it's documented to be numeric, I would go ahead and utilize this as number.
While this is still not clear why the describe would show a different result, but in any case if there's a scenario where there seems to be a discrepancy, I would reach out to Salesforce to make sure the implementation based on documentation will not fail.
Thinking it from a different perspective, if I use a Java Client using CometD to subscribe to an Event, I will always pass an numeric replayId instead of a String value to make sure that I successfully retrieve all replay ids after the value that I am passing.
answered 2 hours ago
Jayant Das
8,8552522
1
Jayant -- The CometD evidence was pretty convincing to me to stick with current plan; will let this marinate a bit to see what other responses come through.
– cropredy
2 hours ago
I am still baffled why does the describe on the field show it as string (I verified it myself). Will see if I can reach out to Salesforce support.
– Jayant Das
2 hours ago
@JayantDas Yes, I'd suggest contacting support. Bugs like this have happened before, and they usually get it fixed.
– sfdcfox
2 hours ago
add a comment |Â
up vote
3
down vote
So, should I care? Or is an assumption of integers good enough?
In my opinion, as long as it's documented to be numeric, I would go ahead and utilize this as number.
While this is still not clear why the describe would show a different result, but in any case if there's a scenario where there seems to be a discrepancy, I would reach out to Salesforce to make sure the implementation based on documentation will not fail.
Thinking it from a different perspective, if I use a Java Client using CometD to subscribe to an Event, I will always pass an numeric replayId instead of a String value to make sure that I successfully retrieve all replay ids after the value that I am passing.
answered 2 hours ago
Jayant Das
8,8552522
1
Jayant -- The CometD evidence was pretty convincing to me to stick with current plan; will let this marinate a bit to see what other responses come through.
– cropredy
2 hours ago
I am still baffled why does the describe on the field show it as string (I verified it myself). Will see if I can reach out to Salesforce support.
– Jayant Das
2 hours ago
@JayantDas Yes, I'd suggest contacting support. Bugs like this have happened before, and they usually get it fixed.
– sfdcfox
2 hours ago
add a comment |Â
up vote
3
down vote
up vote
3
down vote
So, should I care? Or is an assumption of integers good enough?
In my opinion, as long as it's documented to be numeric, I would go ahead and utilize this as number.
While this is still not clear why the describe would show a different result, but in any case if there's a scenario where there seems to be a discrepancy, I would reach out to Salesforce to make sure the implementation based on documentation will not fail.
Thinking it from a different perspective, if I use a Java Client using CometD to subscribe to an Event, I will always pass an numeric replayId instead of a String value to make sure that I successfully retrieve all replay ids after the value that I am passing.
answered 2 hours ago
Jayant Das
8,8552522
So, should I care? Or is an assumption of integers good enough?
In my opinion, as long as it's documented to be numeric, I would go ahead and utilize this as number.
While this is still not clear why the describe would show a different result, but in any case if there's a scenario where there seems to be a discrepancy, I would reach out to Salesforce to make sure the implementation based on documentation will not fail.
Thinking it from a different perspective, if I use a Java Client using CometD to subscribe to an Event, I will always pass an numeric replayId instead of a String value to make sure that I successfully retrieve all replay ids after the value that I am passing.
answered 2 hours ago
Jayant Das
8,8552522
answered 2 hours ago
Jayant Das
8,8552522
answered 2 hours ago
Jayant Das
8,8552522
answered 2 hours ago
Jayant Das
8,8552522
8,8552522
1
Jayant -- The CometD evidence was pretty convincing to me to stick with current plan; will let this marinate a bit to see what other responses come through.
– cropredy
2 hours ago
I am still baffled why does the describe on the field show it as string (I verified it myself). Will see if I can reach out to Salesforce support.
– Jayant Das
2 hours ago
@JayantDas Yes, I'd suggest contacting support. Bugs like this have happened before, and they usually get it fixed.
– sfdcfox
2 hours ago
add a comment |Â
1
Jayant -- The CometD evidence was pretty convincing to me to stick with current plan; will let this marinate a bit to see what other responses come through.
– cropredy
2 hours ago
I am still baffled why does the describe on the field show it as string (I verified it myself). Will see if I can reach out to Salesforce support.
– Jayant Das
2 hours ago
@JayantDas Yes, I'd suggest contacting support. Bugs like this have happened before, and they usually get it fixed.
– sfdcfox
2 hours ago
1
1
Jayant -- The CometD evidence was pretty convincing to me to stick with current plan; will let this marinate a bit to see what other responses come through.
– cropredy
2 hours ago
Jayant -- The CometD evidence was pretty convincing to me to stick with current plan; will let this marinate a bit to see what other responses come through.
– cropredy
2 hours ago
I am still baffled why does the describe on the field show it as string (I verified it myself). Will see if I can reach out to Salesforce support.
– Jayant Das
2 hours ago
I am still baffled why does the describe on the field show it as string (I verified it myself). Will see if I can reach out to Salesforce support.
– Jayant Das
2 hours ago
@JayantDas Yes, I'd suggest contacting support. Bugs like this have happened before, and they usually get it fixed.
– sfdcfox
2 hours ago
@JayantDas Yes, I'd suggest contacting support. Bugs like this have happened before, and they usually get it fixed.
– sfdcfox
2 hours ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f237819%2fplatform-event-replayid-metadata-says-it-is-a-string-of-length-1000-but-eviden%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
