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 .
Related
I've made a quiz app and it's working fine.
I have used an ArrayList to 'store' all the questions I made up myself. Right now it contains 60 questions. I eventually want to expand this to ~300 questions. It looks like this right now:
questions = new ArrayList<>();
Question question0 = new Question(R.drawable.piano, "Welke coureur verkoos een carrière als coureur boven een carrière als pianist?", "Max Verstappen", "Fernando Alonso", "Jean Alesi", "Adrian Sutil", 3);
questions.add(question0);
And I have done this 60 times now. At first I thought I could use a for-loop to add all the questions like :
for (int i=0; i<questions.size(); i++){
questions.add(i);
}
But this is not possible, because the size of the questions is still 0 in the beginning. Now I have a lot of the same code, and I was wondering how to solve it. I could use a database, but I still have to create colums/rows and have to add all the questions. Which takes even more time, right?
I would like to get some advice on what to use and why.
Thanks.
Is it necessary to use a database in my case?
No. However, depending upon what you want from the quiz, a database may be the way to go. If you are just going to present a quiz, the same quiz with the same questions and answers then the App may then no need.
However, if you ventured into storing results, displaying a subset of the questions (e.g. those not attempted or those not answered correctly etc) then you are moving into the realms of the database being desirable perhaps even needed.
I could use a database, but I still have to create colums/rows and have to add all the questions.
Rows would be created by adding the questions.
Which takes even more time, right?
Perhaps not with one of the available SQLite tools, the database could be created using such a tool and then copied into the App (typically as an asset) (more work to implement copying the asset). Of course should the App develop then this could save time (if implemented well).
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! :) ).
I have a CollaborativeString. I'd like to display each Collaborator's cursor position as they are editing it. I can model a cursor using an IndexReference into the string. And I can allow each Collaborator to maintain their own cursor model inside a CollaborativeMap from Collaborator IDs to cursors.
But, what happens when a Collaborator leaves? Since there's no server component, I guess the other users have to handle cleaning dead items out of the map? And what if everyone has left, and there's nobody to clean up the last one? I guess it'd have to be cleaned up by whoever joins next.
I suppose it's not so bad to have all users listening on CollaboratorLeftEvent and racing to delete the corresponding item, since deleting the same item twice shouldn't be much of a problem. Is it a problem? And then I can make another check over the list if you join and you are the first Collaborator, or every time a Collaborator joins so I don't have to worry about faulty clients messing it up.
Am I overlooking a better way of doing this?
I think you basically have the right idea. You should listen for collaborator leave/join events and update what is being tracked appropriately. As you say, its OK for multiple people to make the changes for leave, as they will do the same thing.
The Realtime Playground has an example of this.
I was just wondering if anyone had any good, and most importantly - quick ways of deleting everything in their blocks / media libraries without having to go through every individual item, and moving it to Trash.
This is something I've been having to do before importing fresh data into my site, the only way I have found of doing it efficiently is to put everything into one folder with sub folders within it, this then allows me to delete the folder and all of its contents. But doesn't really help me with my current project where we already have a ton of assets that I don't really want to go through, moving etc..
I'm surprised there isn't a way to simply clear your library, or even select all and then move to trash?
Thanks,
Giuseppe
There is no easy way to do it from the GUI, as far as I know, but you do have the DeleteChildren method on IContentRepository. So creating a scheduled job or a plugin to do it for you should be pretty straightforward.
IContentRepository _contentRepository; // Get this from whereever
var blockRoot = new ContentReference(123); // Get this from whereever, i.e. a property on your startpage
_contentRepository.DeleteChildren(blockRoot, true, AccessLevel.NoAccess);
Also, if you do this on your media data, remember to run the "Remove abandoned BLOBs" scheduled job afterwards (unless it's autorunning on intervals) to clear up disk space.
When you take your first look at an Oracle database, one of the first questions is often "where's the alert log?". Grid Control can tell you, but its often not available in the environment.
I posted some bash and Perl scripts to find and tail the alert log on my blog some time back, and I'm surprised to see that post still getting lots of hits.
The technique used is to lookup background_dump_dest from v$parameter. But I only tested this on Oracle Database 10g.
Is there a better approach than this? And does anyone know if this still works in 11g?
Am sure it will work in 11g, that parameter has been around for a long time.
Seems like the correct way to find it to me.
If the background_dump_dest parameter isn't set, the alert.log will be put in $ORACLE_HOME/RDBMS/trace
Once you've got the log open, I would consider using File::Tail or File::Tail::App to display it as it's being written, rather than sleeping and reading. File::Tail::App is particularly clever, because it will detect the file being rotated and switch, and will remember where you were up to between invocations of your program.
I'd also consider locking your cache file before using it. The race condition may not bother you, but having multiple people try to start your program at once could result in nasty fights over who gets to write to the cache file.
However both of these are nit-picks. My brief glance over your code doesn't reveal any glaring mistakes.