Comments (8)
The only issue I have with this approach is generics. I personally like the generic approach and previously had my own fork of the driver that used generics, but I'm not sure it is really the best idea for backwards compatibility. The question of what Go version to use has was raised to Tobie a few hours ago in #17, but I would imagine he'll want the driver to be as compatible as possible to allow for easier adoption in existing projects. If he okays using newer Go versions, I think it generics should 100% be used.
I've also been working on a solution to this the past couple of days and have my own solution to the issue pretty much finished. I chose to switch everything over to []byte
arrays and mimic Mongo since that was brought up in #18. I also just used the native json package but unmarshalled to json.RawMessage
. I'm not too sure of the performance implications of using json.RawMessage
, but from a few quick searches it seemed to be relatively okay. I'm not sure if the performance would be any better or worse than what you have it you converted it away from generics.
from surrealdb.go.
Yeah i agree, I think there's a way to do it though, I see in some packages, something like this:
So maybe there's a way we can only expose this generic resolver, for go 18+
I hacked together my solution after posting this, I'm going to make a WIP PR, we'll see how people are feeling
from surrealdb.go.
Oh nice, I had no idea build flags like that existed. We should 100% have generics then and just offer other functions for older versions of Go. If you get the generic part to a good state, I would be happy to adjust some of the code I have for the older Go functions.
from surrealdb.go.
Yeah i was doing some digging into them now, I never thought much of it in the past, but seems simple anyway!
https://stackoverflow.com/a/38439941/15727015
So we could use your api for < go 18 and anyone >= 18 would have the option to also use the generic version :D
from surrealdb.go.
json.RawMessage is quite a bit more performant than unmarshalling to a *any, but way less than using jsonparser for just getting the id.
I think the Decoded field is not really necessary though, and we should probably hide the implementation details from the users
from surrealdb.go.
So to start, I was digging through the code, and our issue mainly stems from the fact that we need to decode the main response, to get the RPC ID for handling the callback
I was playing with this
jsonparser
package earlier today with something else, then I realised we might be able to use it here.I did a simple benchmark, and the performance just to get the ID is much faster
My idea:
We can use the jsonparser, to get the id, and then we use a struct like:
type RPCRawResponse struct { ID string Data []byte Decoded *RPCResponse }This "response" can be passed down the channels and such to the end function and only decoded once.
On top of this, we can build a top level "QueryResolver" which uses a generic, and is an opt-in function/struct, which handles context, decoding, checking for errors etc This will take the byte version and pull information out in small pieces, we can also decode once to the final desired output struct from this, rather than Unmarshal -> get id -> Marshal -> Unmarshal -> check for errors and potentially more...
How do we feel about this? I hacked together a crappy version of this "QueryResolver" setup in my project already, but i didn't optimise or care much for code quality as i was just playing, but it's semi elegant to use
Im interested in your solution where you use db.Query[T] to get the results, can you please share your solution? Thank
from surrealdb.go.
So to start, I was digging through the code, and our issue mainly stems from the fact that we need to decode the main response, to get the RPC ID for handling the callback
I was playing with thisjsonparser
package earlier today with something else, then I realised we might be able to use it here.
I did a simple benchmark, and the performance just to get the ID is much faster
My idea:
We can use the jsonparser, to get the id, and then we use a struct like:type RPCRawResponse struct { ID string Data []byte Decoded *RPCResponse }This "response" can be passed down the channels and such to the end function and only decoded once.
On top of this, we can build a top level "QueryResolver" which uses a generic, and is an opt-in function/struct, which handles context, decoding, checking for errors etc This will take the byte version and pull information out in small pieces, we can also decode once to the final desired output struct from this, rather than Unmarshal -> get id -> Marshal -> Unmarshal -> check for errors and potentially more...
How do we feel about this? I hacked together a crappy version of this "QueryResolver" setup in my project already, but i didn't optimise or care much for code quality as i was just playing, but it's semi elegant to useIm interested in your solution where you use db.Query[T] to get the results, can you please share your solution? Thank
In the end I made it into my own lib based on the original: https://github.com/iDevelopThings/surrealdb.go.unofficial
Been a while since i touched surreal stuff, but it should still be fine to use ^^
from surrealdb.go.
@iDevelopThings Nice! Thank you. Have you tested performance?
from surrealdb.go.
Related Issues (20)
- Feature: context.Context Support HOT 6
- Documentation: working with record links HOT 4
- Feature: Move and test `unmarshalMapToStruct(data map[string]interface{}, outStruct interface{})` HOT 2
- Bug: Re-connection to the DB HOT 2
- Bug: Broken Tests for Fetch HOT 5
- Bug: Unhandled errors in websockets can lead to panics HOT 4
- Bug: `Question or idea` Button HOT 2
- surrealdb Auth undefined HOT 1
- Bug: unexpected EOF on TestSurrealDBSuite/gorilla/TestUpdate HOT 1
- Documentation: The README file example is not usable with the latest main branch, neither with the latest version HOT 1
- Feature: Replace Gorilla WS with Nhooyr WS HOT 7
- Bug: The session has expired error when connecting to version 1.3.0 HOT 4
- Bug: stack overflow error in gorilla websocket with db version 1.3.0 HOT 4
- Feature: surrealML for golang
- Documentation: Add Documentation for .Live() func & other stuff related to LIVE queries HOT 6
- Change function does not exist HOT 3
- Feature: Add CBOR support HOT 2
- Bug: UnmarshalRaw panics when unmarshalling object HOT 3
- Feature: UPSERT
- Example fails in Beta 11 - panic: sending request failed for method 'change': Method not found HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from surrealdb.go.