How do you access a Meteor collection that already exists? It's easy enough when you have created the collection in the session because you have a variable that references it, but you can't access a collection by name.
What happens if for example you want to retrieve documents from an existing collection in a new session where it is not being created for the first time. I have tried to 're-create' it hoping that it would just assign the existing collection to the new variable name (seeing that I can't find it by name), but it just throws an error to tell you that the collection already exists.
I've got some externally generated collections that I'm accessing via meteor. I'm not 100% sure that this will answer your question, but I hope it'll at least help.
One gotcha (doesn't apply to you it sounds like, here for completeness) is that if your collection was not created by Meteor, you'll need to export an environment variable to point Meteor to your DB.
For example, if the following env. variable is exported in the shell:
MONGO_URL=mongodb://localhost:3002/foo
...and then you invoke the meteor application, it'll point to the db "foo" in MongoDb, at which point you simply defined your collections as #Akshat mentions above in his comment:
collection = new Meteor.Collection("fooCollection") // this lives inside the foo DB.
If you're dealing with collections that have already been created by Meteor, by default they'll be inside the meteor db, eg:
MONGO_URL=mongodb://localhost:3002/meteor
...and you should be able to simply hook into them the same way; by simply declaring your collection and using it as you would. No need to create, obviously.
It sounds like you're already doing this but for other newcomers like me: in cases like this it's really handy to use the console in Chrome, Firefox, etc. and do some inserts that way - you'll see where your data lands, or you'll see other good bits of information that will help you home in on the issue - console.log() has saved my bacon a couple of times.
At any rate, it's worth validating exactly where the Meteor app is pointing vs. where you think it's pointing. Your collections should be accessible and should Just Work...
Related
I am writing a SwiftUI app that needs to read an external SQLite database. I just need to open the database, query the database, copy values into an array and close the database. Then I need to load the text from one variable in the array to the buttons in a view. I am using the SQLite.swift library but I'm not sure how to do it.
I don't have any code yet but I have loaded the SQLite.swift package and just need to write my DatabaseHelper class and then run it when the View is opened. If anyone can help please reply! :)
Bear in mind that I haven't actually done this, but will have to in the near future. You are going to have to accept the fact that you need to take baby steps and throw out half your work, perhaps multiple times, until you get a satisfactory solution.
I would start by opening your db outside swiftui, probably in the app delegate class. Then stick all your values into the environment object and attach that to your content view
let contentView = ContentView().environmentObject(your_stuff_here)
Down in Swiftui you can extract the details from the environment object and add them to your button.
That should at least get you going.
i am trying to extend alfresco's document management by running a script. So far, i have managed to create a Custom Model with a Custom Type and Property as seen below:
the said Custom Type is under this Custom Model (never mind the Custom Aspect for now)
the custom type is working so far, i managed to apply it to a certain document as you can see below (Notice the Control Code Field)
now what i want to do is to add an auto incrementing function that will be set as the value of the Control Code Property (ie: [FILE0012])
i tried utilizing the scripts rule from alfresco but it seems like the commands are limited to that of alfresco's functionalities. not even alert() or console.log functions work. i thought that if i can make a script that could call an ajax to my php server, i can extract the document's property, and insert it to my database and get the rowid then attach it to a word "FILE" so it becomes the Control Code Property (ie: a document was inserted to my database at row 1996, then the Control code is [FILE1996], this is because i joined '[FILE' and 1996 and ']'
but like i said, what happened was, the javascript commands are limited to that of alfresco's needs.
i tried to make my research but i've only bumped on 2 outdated (and i mean outdated) threads dating back to 2006-2010. which does not help me quite well with Alfresco's current build structure.
i hope someone can help me with here. connecting to the database is not mandatory, but if i can make it do as such then it'll give me quite a rather amazing results.
Take a look at the "cm:countable" aspect. You do not have uniqueness guaranteed OOTB, so take that into account.
Example:
http://www.avantec.se/howto-create-an-auto-increment-field-on-an-object-in-alfresco/
As my Meteor project grows and I add more templates, partials and helpers, it gets harder to figure out what will be the data context for it. Then I'll have to console.log(this) inside a helper function to figure out what's the data I'm dealing with.
Does anybody have a naming scheme or any other strategy to handle this?
Or is this mess just a sign I'm failing to modularize stuff properly and should refactor everything?
For me, each module has a folder. Each folder contains helpers.js, events.js, the "ons" (onCreated.js, onDestroyed.js, onRendered.js) and finally templates.html. If your project is big, break these out into individual subfolders for the necessary CRUD actions (I have a create folder and an update folder because reading & deleting happens in the update templates.
My template names are long and verbose, but that's OK, WebStorm does a good job of guessing what I want. For example, if I had some infowindow that listed all the addresses associated with a client: clientMap, clientMapPopup, clientMapPopupLocationList clientMapPopupLocationListItem.
Regarding data context, it's usually pretty easy to see since my helper is the one that added something to the context. Although I honestly try to avoid using that unless I'm in an {{#each}} because IMHO things like grabbing grandparent context is neither elegant nor robust. Instead, I have a temporary module object that I create & destroy on route changes.
So if my global object is Global = {}. In the onCreated and onDestroyed I write Global.Module = {} Then, I can create all the module-scoped variables I want (ReactiveVars, ReactiveDicts, local collections, primitives, client markers object, etc).
All that said, doing what you do & looking at my schema js (e.g. collections/clients.js) is still the fastest/thoughtless way to see what you want & what you're currently getting.
Although I started using Meteor extensively only recently, the name "Session" for a Session object in Meteor feels like a misnomer to me. It is very different from how it's conventionally used across the web and I don't understand why it's named that way. Is there a specific reason to this or is it possible to rename it to something more suitable?
A Session variable is a reactive data source which:
can be globally accessed anywhere in your client code
will survive a hot code push
will not survive a hard reload
I agree that the name is confusing because of the last point. To answer your question, yes you could name it something else if you really wanted to. For example:
client/lib/session.js
NotReallySession = Session;
Then elsewhere in your client code, you could do:
NotReallySession.set('answer', 42);
NotReallySession.get('answer');
However, I'm not sure what you really gain by doing this.
A more attractive solution would be to use a package like persistent-session which modifies the Session api to give you persistence across page refreshes by keeping values in localstorage.
Of particular interest may be the Session.setAuth function, which stores a persistent reactive value which is cleared on logout. In my view, this most closely aligns with the notion of "session" from other contexts.
I'm trying to figure out a good way to create tutorials for using Meteor apps. Visually, I've figured out a good approach, and packed this into a smart package:
https://github.com/mizzao/meteor-tutorials.
However, there is a second piece that turns out to be rather hard to figure out.
In many cases, a tutorial app needs to be loaded with fake data, to demonstrate the interface to the user without requiring it to be populated with real data that may be hard to generate. (For example, see https://www.planapple.com/trip/demo/349/ which is a demo for PlanApple). In Meteor, since the content of an app is basically defined by the contents of some collections, I see two ways to do this:
Maintain two sets of collections, one for the tutorial and one for the actual app. Use the first set for the tutorial and the second when the user is actually using the app.
Use one set of collections, and fill it with fake data during the tutorial using a subscription and with real data when the user is actually using the app using a different subscription.
The first approach is clearly bad; it means that one cannot write the app without being agnostic to whether it's being used as a tutorial or not and there is a lot of messy if/else reactive logic in presenting the app that is unnecessary. Moreover, this will be very hard to maintain if the app has more than a few collections.
The second approach seems to be the more Meteor-esque way to do things. What we basically want is for a server publication to fill all the client collections with some fake data, and then allow the data to be manipulated in whatever way on the client side without the changes propagating to the server; the client basically gets a copy of the server's tutorial data and then makes only local changes to it which are then discarded. This boils down to two things:
Sending fake data down from the server to client via a custom subscription into the same named collections as the regular app. This is definitely possible as I've written in https://stackoverflow.com/a/18880927/586086
Ignoring any inserts, updates, and deletes from the client (on the server) after the initial load of data; but allowing them to happen locally. This is also possible if one creates null (unnamed) collections, as in http://docs.meteor.com/#meteor_collection.
The problem is that although it's possible to do each of the two steps above separately, I want to do both of them - I want the data to be loaded into the same named collections as the client would have with real data, to avoid the complicated control logic of having two sets of collections, but I also want changes to be local-only but not propagated back over the subscription during the tutorial.
Anyone have ideas about how to do this?
A related question about whether the second part is possible: How does a Meteor database mutator know if it's being called from a Meteor.method vs. normal code?
EDIT: It seems that what we'd basically want to do in the tutorial is inserting directly against the local Meteor Collection as in {https://stackoverflow.com/a/19523301/586086}. However, is there a way to generally turn on this behavior during the tutorial for all relevant mutators, instead of explicitly having to specify this?
I ended up implementing this myself with the partitioner package, which allows connected clients to be divided up into different slices each containing different data.
Basically, the idea is to put the user(s) into a new partition when they are in the tutorial, and then put them into another partition when they are using the app for real. Works great with the tutorials package as well. This gives up the ability of having changes to be client-local, but storing the tutorial data doesn't have much overhead and turned out to be useful in my case anyway.
An example of an app that does this is https://github.com/mizzao/CrowdMapper.