Examples: query, "exact match", wildcard*, wild?ard, wild*rd
Fuzzy search: cake~ (finds cakes, bake)
Term boost: "red velvet"^4, chocolate^2
Field grouping: tags:(+work -"fun-stuff")
Escape special characters +-&|!(){}[]^"~*?:\ - e.g. \+ \* \!
Range search: properties.timestamp:[1587729413488 TO *] (inclusive), properties.title:{A TO Z}(excluding A and Z)
Combinations: chocolate AND vanilla, chocolate OR vanilla, (chocolate OR vanilla) NOT "vanilla pudding"
Field search: properties.title:"The Title" AND text
What is the `int_msg_info` even means here?

This is a great question! (Took me a long time to understand as well)

So basically, you are asking:

  • Why do we store the uint(....) there?
  • And why do we deal with int_msg_info over there?

1/ The message structure

To understand why we store the uint(...) in the message, you need to understand how TVM works for Message. In practice, the Message Layout shows that to "compress" the message we want to store, we must store it into a "Cell" and upload it to the smart contract as the message.

2/ Default values for message fields

There are a series of values we need to set "in default" by giving values for bounced, src, ihr_fee, fwd_fee in some cases.

For example, below is an example for the message we put in a cell:

var msg = begin_cell()
    .store_uint(0, 1) ;; tag
    .store_uint(1, 1) ;; ihr_disabled
    .store_uint(1, 1) ;; allow bounces
    .store_uint(0, 1) ;; not bounced itself
    ;; serialize CurrencyCollection (see below)
    .store_coins(0) ;; ihr_fee
    .store_coins(fwd_value) ;; fwd_fee 
    .store_uint(cur_lt(), 64) ;; lt of transaction
    .store_uint(now(), 32) ;; unixtime of transaction
    .store_uint(0,  1) ;; no init-field flag (Maybe)
    .store_uint(0,  1) ;; in-place message body flag (Either)

3/ The meaning of integers in .store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1)

The integers used in .store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1) indicate the number of bits according to the TL-B scheme, broken down by the length of the fields that are indicated there. But we always indicate 0.

Each integer represents the length in bits of a specific field in the header.

  • The first integer '1' is for the tag field
  • Followed by two '4's for ihr_disabled and bounce fields
  • Then 64 bits for created_lt field
  • 32 bits for created_at field
  • and finally two '1's for init and body fields.

However, in the example given, all the fields are empty, so we indicate 0 bits for all the fields.


Posted 8 months ago
Edited 7 months ago
0 Answers
8 months ago
8 months ago