Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Couchbase.Extensions.Session - can data be stored as raw JSON? #60

Open
mgroves opened this issue Nov 15, 2018 · 3 comments
Open

Couchbase.Extensions.Session - can data be stored as raw JSON? #60

mgroves opened this issue Nov 15, 2018 · 3 comments

Comments

@mgroves
Copy link

mgroves commented Nov 15, 2018

When using the SetObject extension, data is stored in Couchbase like so:

{
	"sessionkey": "eyJVc2VyTmFtZSI6IkZlbGlwZV9Qb3dsb3dza2kyNyIsIlNNUyI6IjEtODY5LTM5Ny00MjM4In0=",
	"sessionkey2": "eyJSZWdpb24iOiJBWiIsIkVtcGxveWVyIjoiT2JlcmJydW5uZXIgLSBTY2h1bW0ifQ=="
}

Which appears to be an encoded byte array.

But it seems like this is a change in behavior since 1.0.0-beta2, which would store as literal JSON (see blog post https://blog.couchbase.com/distributed-session-aspnet-couchbase/):

{
	"sessionkey": {
		"name": "Matt",
		"twitter": "@mgroves",
		"guid": "2017-09-19T10:47:43.2705915-04:00"
	},
	"sessionkey2": {
		"address": "123 Main St",
		"city": "Lancaster",
		"state": "OH"
	}
}

It's not the end of the world if it must be the former, but it does limit analysis on sessions that can be done with N1QL/SQL++/Analytics/FTS. Is it possible there was a change (in the extension or in ASP.NET Core) that caused this? Is it possible to switch it back to storing JSON (or at least to give the option of storing in JSON)?

@mgroves
Copy link
Author

mgroves commented Dec 12, 2018

This appears to be the commit where it was changed from storing object to storing bytes: 8596da3#diff-f335e5d1377d3fa2cefb1971286defd6

This was part of a larger commit called "upgrade to core 2.0", so it looks like this might have been required by asp.net. I'm going to investigate further to see if it's possible to go back and/or have both options (byte array and raw json)

@mgroves
Copy link
Author

mgroves commented Dec 12, 2018

I took a hack at this, and I just don't see a way to make this work with the ISession interface the way it is. Basically what I did was try to switch _store back to a dictionary of object (instead of byte array), which mostly works!

But where it falls apart is SessionTests. The tests fail because GetString, GetInt32, SetString, and SetInt32 are all used, and I just don't see any way to differentiate between them. ASP.NET expects them to be stored as byte values. If I try to accommodate that (mainly in TryGetValue), then something ends up getting corrupted. I can get most of the tests to pass, but then it becomes whack-a-mole.

This is kinda lame, because I think the power in using Couchbase for a session store comes with being able to query/index it with N1QL/Analytics/MR/etc. Having the values encoded as base64 means that I have to choose between building my own session store or foregoing that Couchbase power.

@mgroves
Copy link
Author

mgroves commented Dec 13, 2018

There's actually a kinda cool workaround for this. Not ideal, but pretty good.

Say I have a session document like so:

  {
    "location": "eyJDbG9zZXN0U3RvcmVMb2NhdGlvbiI6IjIzMDIgVG9ycCBSZXN0LCBDb25yb3lsYW5kLCBOYW1pYmlhIiwiR2VvQ29vcmRpbmF0ZXMiOnsiTGF0IjotNS44MzIsIkxvbiI6MjEuMjA2fX0=",
    "preferences": "eyJSZWdpb24iOiJQQSIsIkVtcGxveWVyIjoiQnJ1ZW4gSW5jIn0=",
    "user": "eyJVc2VyTmFtZSI6IkphbHluX0ZheTkiLCJTTVMiOiIoMzgwKSAyMjctMTUxNSJ9"
  }

Not terribly useful for N1QL querying. BUT, there's a BASE64_DECODE function that works perfectly on this. For example:

select
   BASE64_DECODE(s.location) AS location,
   BASE64_DECODE(s.preferences) AS preferences,
   BASE64_DECODE(s.`user`) AS `user`
from sessionstore s
WHERE BASE64_DECODE(s.`user`).UserName = 'Jalyn_Fay9';

That returns:

[
  {
    "location": {
      "ClosestStoreLocation": "2302 Torp Rest, Conroyland, Namibia",
      "GeoCoordinates": {
        "Lat": -5.832,
        "Lon": 21.206
      }
    },
    "preferences": {
      "Employer": "Bruen Inc",
      "Region": "PA"
    },
    "user": {
      "SMS": "(380) 227-1515",
      "UserName": "Jalyn_Fay9"
    }
  }
]

So, it's a little extra work to do the decoding (and corresponding indexing), but it does work. It would still be much easier (for N1QL) if the data stored was not encoded in the first place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant