Recently am working Database (SQL) . And we have enabled GET,GET/{ID},POST/ PUT[{ID} Operations for client.
Client came up and asking what about Patch !!!
I know the diff b/w Put and Patch. you want to update with whole payload or just few fields .
GET-SELECT
POST-INSERT
PUT-UPDATE
PATCH- ?
FYI: my api PUT/{ID} works even with whole payload or small payload.
In true senseof the word, both PUT and PATCH point to a DB UPDATE operation.Since you're already aware of differences b/w PUT/PATCH and your API PUT/{ID} is able to handle whole/partial update, there's practically no point in having another PATCH method(unless it pleases your client! :) ).
Related
Currently i am using the REST interface to query vespa, which seems to work great but something tells me that i should be using searchers in the application to make the client(server side code) a bit lighter (bundle the jar file in the application package) to make it a bit smoother. I have managed to do some simple searcher/processor applications. But this is a bit overwhelming.
So are there any readily available examples ?
Basicially i want to:
Send to /search?query=someId
Do a ordinary search for the weighted set on this documentID (I guess this one can be handy: https://docs.vespa.ai/documentation/reference/inspecting-structured-data.html)
Take those items in the response and add it to a wand item(s) and query for a wand with wandsearcher on a given field. Similar to the yql:
"select * from sources * where wand(interest, some weightedsets));","ranking":"combined_score" and return the matches.
Just curious also, apart from the trouble of string building with the http request i am doing at the moment are there any performance gains of using a searcher or go the java route vs rest?
thanks for any insight or code help i can start with.
There is an example of using the WandItem (YQL wand)here https://docs.vespa.ai/documentation/advanced-ranking.html and see also https://docs.vespa.ai/documentation/using-wand-with-vespa.html as there are two wand implementations available in Vespa, it sounds from the description that the wand() is what you want to use for this use case. For the first call you probably want to have a dedicated document summary to reduce the amount of data fetched for your first query and also the option of serving it out of memory only (See https://docs.vespa.ai/documentation/document-summaries.html)
Also see https://docs.vespa.ai/documentation/searcher-development.html as a general resource on writing searchers.
For your use case it makes a lot of sense to write a searcher to perform these two queries as your second query depends on the first and you avoid the cost of rendering/http/yql parsing which might matter if your client is remote with high network latency.
I were working on my app today and when my friend looked on my code he told me that before I'm making an HTTP request to update objects I should remove the properties that are not used in my server and I didn't understand why.
I didn't find any best practice or any explanation on the web why it is better to clean my objects before sending them to my server...
Let's say I have a dictionary with 100 keys & values with the same properties (but different values) like this one:
{
'11':{'id':11, 'name':'test1', 'station':2, 'price': 2, 'people':6, 'show':true, 'light': true},
'12':{'id':12, 'name':'test2', 'station':4, 'price': 2, 'people: 1, 'show': true, 'light': false},
....
}
The only thing I need to change is the station of each pair. The new station number is set on my client and sent to my server to make an update in my DB for each pair...
Should I iterate over the dictionary and clean every object before making an HTTP request to my server as my friend said?
I can not add a comment because of my reputation, so I'll put as an answer
Not necessarily, it depends a lot on how your server's API works, if it expects an entire object, it's no use cleaning, now if you have the option to send only the modified element, you do not have to send the entire object.
The HTTP request will work in the same way with a single piece or with an integer object, but you can shorten the data traffic in kbps by sending less, only the Required, like as the changed values
Summary, it depends a lot on your approach, working single values and not whole objects you can do more generic functions and improve their entire scope.
Check: THIS It's similar to your question.
EDIT:
Maybe the cleanup he's referring to, is the question of clearing the code and sending only the necessary, so I understood the scope of the question
Remember that the less you pass, the more intact the original object will be (on the server).
It is a good practice to create generic (modulable) functions that only work with the necessary changes.
Couple reasons that come to mind:
plan for the unknown: today, your server doesn't care about the people attribute. But imagine you add something server side and a people attribute appears and is a string. Now all your clients fail, because they try to push numbers to a string
save the world: data is energy, and you're wasting it by sending more data that your server can handle, even if it's just a little
save your own energy: sending more attributes is likely to mean more work (to write the code and/or test it)
I have been developing some things and you know during early prototyping types and tables change quickly... it would be nice to cleanup the old data and start again in certain meshes.
For now I was using the example HTTP server so I deleted data.json; but I forgot the localStorage in the browser also needs to be cleared.
One might suppose you could put(null)
I asked on gitter and got
https://github.com/amark/gun/wiki/delete
except for deletes , lol, our excuse is "It works like your OS, when you delete >something it just gets tossed in the trash/recycle bin. That's all."
better safe than sorry though
if you are trying to "delete" stuff because you messed up while developing >something, follow this three step process: 1) localStorage.clear() in every >browser tab you have up, 2) Crash the server and rm data.json, 3) restart >everything. You should then have a clean slate. Often times while I'm >devleoping something I put localStorage.clear() at the top of my code so I only >have to worry about clearing the server.
Welcome to the gun community! Thanks for asking questions.
Yes, deleting data is most simply done with gun.put(null). Take:
var gun = Gun();
var users = gun.get('users');
users.put({alice: {name: 'alice'}, bob: {name: 'bob'}});
// now let's delete bob
users.path('bob').put(null);
If (as you mentioned in the question) however, you mean "delete data" as in wanting to clear out mistakes while developing your app. You'll want to do what you mentioned: localStorage.clear() in all browsers, crash the all servers and rm data.json.
For other developers, it might be useful to know that gun uses a type of tombstone method. You can't actually delete nodes themselves, they just get de-referenced, kinda like how your OS just moves files into a trash/recycle-bin. This tombstone method is very important in a distributed environment, such that the "delete" operation is replicated to every peer.
Thanks for answering your own question though! As always, if you get lost or need help hop on the https://gitter.im/amark/gun .
In my old cakephp 2.x Applications, the password hash was hidden by '*' when I retrieved the data from the User Model. I am not a hundret percent shure, but I think this was done automaticly by Cake.
Now testing Cakephp3.0, I am surprised finding the complete hash when retrieving data from the User Model.
I got a few questions concerning this password-hash-hiding:
Am I right with my opinion this was a function in cakephp2?
Does anyone know, why this function was not implemented in Cakephp3 and why?
If I am wrong by assuming this was included in cake, where is the place to implement this functionality in cake2 and cake3?
Thank you very much for your help.
Am I right with my opinion this was a function in cakephp2?
Yes, in Cake 2.x this is part ot the Debugger, the data itself however is not being touched, just some of the content is being masked when outputting the data.
Does anyone know, why this function was not implemented in Cakephp3 and why?
It is still implemented, but it has been moved. The whole point of this masking thingy was to avoid accidental exposure of datasource credentials (mainly in error messages/pages), it never really had something to do with possible user model data, this is just a side effect for data that happens to use keys like password.
So in 3.x this functionality has been moved to \Cake\Database\Connection::__debugInfo()
https://github.com/cakephp/cakephp/pull/4542
This ensures that you'll still end up with masked credentials when for example debugging connection objects, being it explicitly, or implicitly on error pages, while it doesn't obstruct debugging other data anymore.
[...], where is the place to implement this functionality in [...] cake3?
This highly depends on your use case, if you'd for example wanted to have it masked in debug output, then you could implement it in an overriden __debugInfo() method in your user entity class, similar to how the Connection class is doing it.
https://github.com/cakephp/cakephp/blob/3.0.11/src/Database/Connection.php#L702
Of course this would only work for entities, not for non-hydrated data (array data).
Suppose that one needs to send the same collection of 10,000 documents down to every client for a Meteor app.
At a high level, I'm aware that the server does some bookkeeping for every client subscription - namely, it tracks the state of the subscription so that it can send the appropriate changes for the client. However, this is horribly inefficient if each client has the same large data set where each document has many fields.
It seems that there used to be a way to send a "static" publish down the wire, where the initial query was published and never changed again. This seems like a much more efficient way to do this.
Is there a correct way to do this in the current version of Meteor (0.6.5.1)?
EDIT: As a clarification, this question isn't about client-side reactivity. It's about reducing the overhead of server-side tracking of client collections.
A related question: Is there a way to tell meteor a collection is static (will never change)?
Update: It turns out that doing this in Meteor 0.7 or earlier will incur some serious performance issues. See https://stackoverflow.com/a/21835534/586086 for how we got around this.
http://docs.meteor.com/#find:
Statics.find({}, {reactive: false} )
Edited to reflect comment:
Do you have some information that the reactive: false param is only client side? You may be right, it's a reasonable, maybe likely interpretation. I don't have time to check, but I thought this may also be a server side directive, saying not to poll the mongo result set. Willing to learn...
You say
However, this is horribly inefficient if each client has the same large data set where each document has many fields.
Now we are possibly discussing the efficiency of the server code, and its polling of the mongo source for updates that happen outside of from the server. Please make that another question, which is far above my ability to answer! I doubt that is happening once per connected client, more likely is a sync between app server info and mongo server.
The client requests you issue, including sorting, should all be labelled non-reactive. That is separate from whether you can issue them with sorting instructions, or whether they can be retriggered through other reactivity, but which need not include a trip to the server. Once each document reaches the client side, it is cached. You can still do whatever minimongo does, no loss in ability. There is no client asking server if there are updates, you don't need to shut that off. The server pushes only when needed.
I think using the manual publish ( this.added ) still works to get rid of overhead created by the server observing data for changes. The observers either need to be added manually or are created by returning a Collection.curser.
If the data set is big you might also be concerned about the overhead of a merge box holding a copy of the data for each client. To get rid of that you could copy the collection locally and stop the subscription.
var staticData = new Meteor.Collection( "staticData" );
if (Meteor.isServer ){
var dataToPublish = staticData.find().fetch(); // query mongo when server starts
Meteor.publish( "publishOnce" , function () {
var self = this;
dataToPublish.forEach(function (doc) {
self.added("staticData", doc._id, doc); //sends data to client and will not continue to observe collection
});
});
}
if ( Meteor.isClient ){
var subHandle = Meteor.subscribe( "publishOnce" ); // fills client 'staticData' collection but also leave merge box copy of data on server
var staticDataLocal = new Meteor.Collection( null ); // to store data after subscription stops
Deps.autorun( function(){
if ( subHandle.ready() ){
staticData.find( {} ).forEach( function ( doc ){
staticDataLocal.insert( doc ); // move all data to local copy
});
subHandle.stop(); // removes 'publishOnce' data from merge box on server but leaves 'staticData' collection empty on client
}
});
}
update: I added comments to the code to make my approach more clear. The meteor docs for stop() on the subscribe handle say "This will typically result in the server directing the client to remove the subscription's data from the client's cache" so maybe there is a way to stop the subscription ( remove from merge box ) that leaves the data on the client. That would be ideal and avoid the copying overhead on the client.
Anyway the original approach with set and flush would also have left the data in merge box so maybe that is alright.
As you've already pointed out yourself in googlegroups, you should use a Meteor Method for sending static data to the client.
And there is this neat package for working with Methods without async headaches.
Also, you could script out the data to a js file, as either an array or an object, minimize it, then link to it as a distinct resource. See
http://developer.yahoo.com/performance/rules.html for Add an Expires or a Cache-Control Header. You probably don't want meteor to bundle it for you.
This would be the least traffic, and could make subsequent loads of your site much swifter.
as a response to a Meteor call, return an array of documents (use fetch()) No reactivity or logging. On client, create a dep when you do a query, or retrieve the key from the session, and it is reactive on the client.
Mini mongo just does js array/object manipulation with an syntax interpreting dsl between you and your data.
The new fast-render package makes one time publish to a client collection possible.
var staticData = new Meteor.Collection ('staticData');
if ( Meteor.isServer ){
FastRender.onAllRoutes( function(){
this.find( staticData, {} );
});
}