How do I set MONGO_URL from within my Meteor app?
I tried
process.env.MONGO_URL = '...'
in my server-side code, outside Meteor.startup, but that isn't working.
I'm using demeteorizer to bundle it into a node.js app. I can't set MONGO_URL in Terminal directly (I'm running my app on a third-party provider).
From Meteorpedia: Environment Variables.
Setting the value of an Environment Variable
The safest time to do this with guaranteed behaviour for any variable
is BEFORE METEOR STARTS. This is usually done either through your
PaaS provider's control panel for your app, or in the shell script
that launches Meteor, e.g.
IMPORTANT: You can also set/change an environment variable from inside Meteor, but you need to set it before it's used. e.g. it's too late to
set MONGO_URL after Meteor has been loaded, but MAIL_URL is ok since
you'll get it set before any mail is sent.
You can overwrite the default collection driver
MongoInternals.defaultRemoteCollectionDriver = _.once(function () {
return new MongoInternals.RemoteCollectionDriver(Meteor.settings.MONGO_URL, {
oplogUrl: Meteor.settings.MONGO_OPLOG_URL
});
});
or set it manually per collection
var database = new MongoInternals.RemoteCollectionDriver(Meteor.settings.MONGO_URL, {
oplogUrl: Meteor.settings.MONGO_OPLOG_URL
});
somecollection = new Mongo.Collection('somecollection', {_driver: database});
Related
I'm trying to get rid of the "Config:" prefix added by AddServiceFabricConfiguration with AspNet Core to follow the same naming regardless of configuration source.
According to the documentation you should set IncludePackageName = false which I do like this:
.ConfigureAppConfiguration(builder => {
builder.AddServiceFabricConfiguration(serviceContext.CodePackageActivationContext, options => options.IncludePackageName = false);
})
But when I'm running the application the configuration is populated like this with IncludePackageName set to true anyway.
How can I make this setting work? The ServiceFabricConfigurationProvider which the helper adds is not public so I can't find a suitable workaround.
Update: This seems to have been some issue with my local environment rather than the actual code. Reboot, clean and rebuild fixed the issue.
I have added a custom locator in protractor, below is the code
const customLocaterFunc = function (locater: string, parentElement?: Element, rootSelector?: any) {
var using = parentElement || (rootSelector && document.querySelector(rootSelector)) || document;
return using.querySelector("[custom-locater='" + locater + "']");
}
by.addLocator('customLocater', customLocaterFunc);
And then, I have configured it inside protractor.conf.js file, in onPrepare method like this:
...
onPrepare() {
require('./path-to-above-file/');
...
}
...
When I run my tests on the localhost, using browser.get('http://localhost:4200/login'), the custom locator function works absolutely fine. But when I use browser.get('http://11.15.10.111/login'), the same code fails to locate the element.
Please note, that the test runs, the browser gets open, user input gets provided, the user gets logged-in successfully as well, but the element which is referred via this custom locator is not found.
FYI, 11.15.10.111 is the remote machine (a virtual machine) where the application is deployed. So, in short the custom locator works as expected on localhost, but fails on production.
Not an answer, but something you'll want to consider.
I remember adding this custom locator, and encounter some problems with it and realised it's just an attribute name... nothing fancy, so I thought it's actually much faster to write
let elem = $('[custom-locator="locator"]')
which is equivalent to
let elem = element(by.css('[custom-locator="locator"]'))
than
let elem = element(by.customLocator('locator'))
And I gave up on this idea. So maybe you'll want to go this way too
I was able to find a solution to this problem, I used data- prefix for the custom attribute in the HTML. Using which I can find that custom attribute on the production build as well.
This is an HTML5 principle to prepend data- for any custom attribute.
Apart from this, another mistake that I was doing, is with the selector's name. In my code, the selector name is in camelCase (loginBtn), but in the production build, it was replaced with loginbtn (all small case), that's why my custom locater was not able to find it on the production build.
I'm using js-data (and js-data-angular) in conjunction with sockets via sails.js. When a new item is created/updated via sockets I want to call attention to it in my ui.
I'd like to add an "updated" property to the object, but don't want to inadvertently persist it to the DB.
Is there a way to hang non-persisting properties on a js-data object?
Yes.
You can set this globally on the data store or per-resource by using the omit configuration setting. For instance, when instancing your data store, you can instruct JSData to ignore all properties that begin with an underscore:
var store = new JSData.DS({ omit: [ /^_/ ] });
The documentation for the meta property of the options passed to store.defineResource says:
Put anything you want here. It will never be used by the API.
I'm using the packaged app version of Postman to write tests against my Rest API. I'm trying to manage state between consecutive tests. To faciliate this, the Postman object exposed to the Javascript test runtime has methods for setting variables, but none for reading.
postman.setEnvironmentVariable("key", value );
Now, I can read this value in the next call via the {{key}} structure that sucks values in from the current environment. BUT, this doesn't work in the tests; it only works in the request building stuff.
So, is there away to read this stuff from the tests?
According to the docs here you can use
environment["foo"] OR environment.foo
globals["bar"] OR globals.bar
to access them.
ie;
postman.setEnvironmentVariable("foo", "bar");
tests["environment var foo = bar"] = environment.foo === "bar";
postman.setGlobalVariable("foobar", "1");
tests["global var foobar = true"] = globals.foobar == true;
postman.setGlobalVariable("bar", "0");
tests["global var bar = false"] = globals.bar == false;
Postman updated their sandbox and added a pm.* API. Although the older syntax for reading variables in the test scripts still works, according to the docs:
Once a variable has been set, use the pm.variables.get() method or,
alternatively, use the pm.environment.get() or pm.globals.get()
method depending on the appropriate scope to fetch the variable. The
method requires the variable name as a parameter to retrieve the
stored value in a script.
I have searched and searched for this but I think my terminology isn't correct as it keeps giving me the application settings for the zend site rather than an application settings for the End User.
I'd like to have a config.ini type file that the end user can edit values in. I'd like it to be ONLY the settings I wish them to see and to be able to create the value names as I think would make sense to them. So it would be something like
[General]
SiteName=MySite
ShowResources=TRUE
[Database]
Server=myServer
databasepath=mydbpath
...
So my two questions.
1. What is this type of file called because when I search application settinsg, I get the ZF application settings not one for an end user (presumably)
What is the best way to handle this type of file?
Thanks
In your bootstrap add:
protected function _initConfig()
{
$config = new Zend_Config_Ini(APPLICATION_PATH.'/configs/config.ini');
Zend_Registry::set('config', $config);
return $config;
}
replace config.ini with whatever you want the filename to be.
You can then access this config object anywhere in your application either as an application resource or through the registry (Zend_Registry::get('config')). So to get the SiteName from your example:
$config = Zend_Registry::get('config');
echo $config->General->SiteName;
For things like database settings, you'll want to access these in the bootstrap so you can use them to setup other resources. I would recommend you don't try and include database settings in your application.ini as well, instead manually setup the DB resource by adding another bootstrap method:
protected function _initDb()
{
$this->bootstrap('config');
$config = $this->getResource('config');
$db = Zend_Db::factory('Pdo_Mysql', array(
'host' => $config->Database->Server,
'username' => $config->Database->Username,
'password' => $config->Database->Password,
'dbname' => $config->Database->Dbname
));
return $db;
}
To explain this some more, $this->bootstrap('config'); ensures the config resource is loaded first. $this->getResource('config'); returns the config resource (the one created by the _initConfig() method). It then uses the data from this object to create the DB connection.
It's an INI file, which you can read and write via Zend_Config.
ZF has no concept of "user settings" -- users are defined by you, not by the framework.
Apps usually store user configs in a database, but that's totally up to you. You could store a directory of INI files instead. Either way, you have to do the implementation yourself.
Edit: Given that you have a ZF app that you're distributing to the customer, and they're only ever going to connect to one database with it, that changes things significantly. (I thought you originally meant that you'd have one instance of the app simultaneously connecting to multiple databases.)
In your case, I would use the standard ZF application/configs/application.ini file for your application's "internal" settings. Then, I'd have a separate local.ini (or whatever) in that same application/configs directory, which contains only those settings that you want the customer editing. Distribute a skeleton local.ini file with the app, that has instructions right in it, something like this:
; Remove the comment from this line.
;configured = 1
; You need to put your database credentials in here.
db_host = "PUT YOUR DATABASE SERVER NAME HERE"
db_user = "PUT YOUR DATABASE USERNAME HERE"
db_pass = "PUT YOUR DATABASE PASSWORD HERE"
Then just load the local.ini file via Zend_Config. I'd also add a check to your index controller's init method that checks to see if you're properly configured:
$localConfig = Zend_Registry::get('local_config'); // or wherever you put it
if (!$localConfig->configured) {
$this->_helper->redirector('config', 'error');
}
And then make a error/config view that says:
You didn't read the instructions. Go do that now.
Note there's nothing stopping the customer from editing anything they want, but this makes a logical separation and makes it harder to accidentally screw something up.