{
"data": {
"message": [
{
"message": "really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message really long message "
}
]
},
...
}
But I would like my returned data to have a shortened preview version of message, something like the following
"message": "really long message rea"
Is there any way in dgraph query language to return a substring like this?
Would love your input and support for this feature request:
I know this is DQL specific and not GQL, but if these functions get added into DQL, then we could make another feature request about getting these functions supported as directives on string fields. That might look something like:
# directive defined
directive @function(func: Function! props: [String]) on FIELD_DEFINITION
enum Function {
left
lTrim
replace
reverse
right
rTrim
split
substring
toLower
toUpper
trim
}
# example use
{
message (func: uid(0x4e22)) {
message @function(func: left, props: ["23"])
}
}
The reason why I want to “preview” a string in this way is so that it doesn’t need to be sent over network in its entirety, as the messages can potentially be very long. In this regard, being able to shorten the string on the client application end does me no good.
The use case here is previewing a large network of messages and having a short preview of the content of each. Without string functions, the only solution here is to insert a second string containing the preview upon message creation, which seems a bit burdensome as it requires adding complexity and changes at multiple application layers to facilitate what is conceptually a simple, one step task. I will likely hold off on this idea until a better solution is possible.
@amaster507
Unfortunately as a very new beginner to dgraph and graph databases, I can’t offer much beyond an agreement that these features will be much appreciated.
Dunno if that approach (“sneak pick preview”) would be a good solution. I think that would be better to have a filtering strategy instead. Cuz, if you gonna have big texts, who guarantees that the part of the text you need is in the beginning? Think about that.
And if you can guarantee that, I doubt that others would make the same pattern as yours. So it would be better to have a universal solution than a specific for one or a few people.
Filters like allofterms and others might help here. And also custom ontology via edges might be useful the predict what you need before querying.
“sneak peak preview” is exactly what I’m trying to achieve here. I believe this is a common use case. Imagine almost any search results page you’ve seen, or try just searching something on this website. When a match is found in a long post, a substring is returned. Hence the wording of my original question / title. I believe that “substring” is a very universal solution to many problems, and it seems to be a base feature in nearly every language environment that has strings.
The substring can always be extracted in the client application, but since there is no limit (or very large limit) to the size of the sting, and it is user generated data, it would seem unwise to request a large result set, such as a search results page, including every string in it’s entirety. Beyond being wasteful of bandwidth and memory allocations, this dramatically increases the bounds of what resources may potentially be needed for requests that only need to return small results. The only solution that does any good in this regard is to be able to shorten the data on the database side before transmission, i.e. a substring function.
Anyway, I don’t find it too productive to discuss these things here. The original question has been asked and answered, and for now I will just move on.
As @amaster507 mentioned, this is part of an ongoing feature request, and as such, this thread will be updated when there are movements on the feature request.