Well why even allowed for any setBlob in the first place as a convenience method, just make the user do it all create the key and then adding single blob or array of blobs with their own way. Instead gives you a convenience method of creating single blob and associating it with a key and then leaving you wanting to figure if it has a function that can add more than just a single blob from calling setBlob, maybe there should be a setBlobs function added.
And yes that is what I would like to do the document, and I can do this from the server side or access this document in a different way. I don’t see why there is not a setBlobs(values: [Blobs], forKey: “images”) instead of just having setBlob(value: Blob, forKey: “image_1”) let’s say.
Borrrden has been helpful and understood and answer my question. I appreciate your help however in pushing the idea of creating array and adding blobs to it without a convenience method to set it to key such as setsblob. I’ve used your documentation about 4 years while there’s was barely none, and still today there’s JavaScript+pseudo code that doesn’t work. Hopefully your editor can help the community better unless it was a strategy get us to get a pro version and pay you to school us on cs basics and array as if we don’t already know. Thanks.
Out of curiosity: What did @borrrden tell you that helped? Was it pointing out that blobs don’t have to be at the top level of a document?
(Also, regarding iterating keys, which I think you said wasn’t possible: you can either use the Dictionary.keys property to get all the keys and iterate that, or you can use platform-specific syntax like a for...in loop.)
Let’s start over. What I thought was not possible was counting blobs conveniently after adding them one by one in document. Originally I thought when I set a blob one by one to add it to a document using doc.setblob(forKey: someImageKey). I would be able to call doc.blob(forKey: _attachments).count and get all the blob count. It confirmed that attachments can’t be used, it’s for migrating 1x on server side. So there’s a function however to call doc.blob(forKey: yourImageBlobKey). Which is confirmed that it was use for one key for one blob. So my question is why you don’t also have a setBlobs(forKey: images) so we can get blobsForKey and it returns a mutable array or whatever array. And then easily count that. Instead you’re saying just add blob to mutable array and slap into a made key, we’ll there’s not a set mutablearray to key again like setBlobs(many), there’s only setBlob (1). So Borrrden said why don’t I just create a int key in document. Then increment that value. So after going through that, I’ve concluded sure, but why does setsBlob not make sense to have?
Question 1:
Is there a reason why there is not setsBlob(many)?
If so reason is provided for question 1,
Question 2:
Is there a reason why there is setBlob(1) only if there’s a reason for question 1?
I’ve been suggesting two solutions which I think you are confusing as one. They are
Put the blobs into an array
If you don’t want to do that, then keep a count in your document
The difference between the two approaches is that in approach in 2 you can have a unique key per blob, but with approach 1 they will just be entries in an array.
As far as the questions:
The reason is because it doesn’t add anything of value.
Because blob is one of the core data types we support (in addition to string, int, etc). You seem to be holding on to the idea that blobs are somehow special. They were in 1.x, but they are not anymore.
Our data format is to support JSON Types plus blob → string, numerics, arrays, dictionaries, and blob. So why would we provide a setBlobs function and not a setStrings function or setFloats function. If you want an array of things for a key, then create an array on that key (setArray using an array containing the blobs).
I have a reason why it add values though. Array of blob is not conforming to codable protocol in swift. Not an array of strings, so if it is added to top level, won’t have this problem.
There aren’t methods to create an array of anything (blobs, strings, ints, whatever) because there are already methods to create an array and to add objects to an array, and it’s easy enough to use those.
I have no idea why you’re talking about arrays of blobs not conforming to Codable. We don’t use that protocol.
Maybe if you could clearly describe, in detail, what you’re trying to do, instead of complaining about your mistaken ideas of the API, then we could help?
In current swift 4, 4.2 to be exact. Everyone who deals with json in an iOS environment if the project is swift, most likely they are creating classes that conforms to the codable protocol which enables for very easy json serialization and deserialization. If I was to create a class/struct that had of type string int or array of that as value for key, it would conform. The moment I use [blob] an array of blob as type, it no longer conform to that codable protocol and then that mean I have to go do json parsing the old way. Which is the old way and really long way to parse json. So the value added here is for people to quickly use your couchbaselite without slowing up development time. A lot of other service out there understand this and is on top of the game for make it as easy for the user to use. So I’m saying it does add value to have something like that. Most people use json, so json parsing is made easy in swift 4 by conforming to this protocol. Because blobs are no longer special, not only we have to create an array and assign it to the document, we have to not use this protocol and go back parse the json a different way
Jens I’m talking about for swift projects/iOS. I’m talking about adding value, not something is wrong? Borrrden already explained it and I think it’s fair how everything work, but I’m telling you why there is value to do it like so. A suggestion? You’re taking it a bit of context again. Don’t think too hard, just making a suggestion. You’re like 300 steps ahead in your thinking but it doesn’t really match up what we’re talking about. And I have suggested to have Ms. Priya to confirm this, should understand why we might need something like this for a swift project. We shouldn’t go backward in making things harder, it should always be easier going forward. Don’t you think increasing developer development by making it easier help the business. It shouldn’t be like it’s doable approach. It should be let’s make it a no-brainer approach.
Look I understand you don’t understand why I’m suggesting this. I’m a single developer been working on an app for quite sometime on the side and had the patience to deal with couchbase for 4 years now. From views to what seem like a great concept over sql query, to you guys finally switching to n1ql to allowing us to be closer to sql and still in a swift project we have to create joins and expression over actually just copying a sql statement in plain txt, instead we create our query then convert it to your expression before use. Everything seems behind, but that’s fine because couchbase concept for other stuff is great. But for me I’m just going to have to push some ideas so you can everybody life easier and would increase adoption for your platform. At least by smaller business, I understand the bigger company use you as things scale, but the entry level for using your platform is not easiest compare to firebase, given yes you guys have different benefits. Unless that’s not your target, quick up and running should be the goal here. By adding it small function and treating blobs special would help the iOS community.
Lack of convenience methods isn’t the same thing as missing functionality. Your earlier complaints were that you thought it was impossible to create an array of blobs, or to iterate all the blobs in a document. We showed you how to do that.
Yes, we have fewer convenience methods than we could. I personally would like to see more. That’s something that will likely happen as we go forward.
There’s also not a lot of platform-specific integration, like Swift’s Codable interface as you pointed out. We decided to make the API as cross-platform as possible in 2.0, since a lot of developers build apps for multiple platforms. But I feel that we should add more integration features. Binding docs to native objects is important — I created the CBLModel class in 1.0 for that. We do want to bring that kind of functionality back, but we’ll need to implement it for each platform, and those implementations will be different, so it’ll take significant work.