I am trying to setup a light weight application with Express.js. I would like to use Sqlite3 for storage.
I need some sort of session management and trying to use the session management module described in the Express guide document like so (CoffeeScript)
g.app.configure ->
g.app.set 'views', "#{__dirname}/views"
g.app.set 'view engine', 'jade'
g.app.use g.express.bodyParser()
g.app.use g.express.cookieParser()
g.app.use g.express.session(secret:'cruel')
g.app.use g.express.methodOverride()
g.app.use g.app.router
g.app.use g.express.static "#{__dirname}/public"
Now I would like to store the sessions either in sqlite3 or as files in the project path somehow.
All examples I find use different kinds of NoSql-databases.
Could anyone shed some light on where to find other session store modules, or even how to implement one.
I think these 3 links will be useful for you:
http://senchalabs.github.com/connect/middleware-session.html (at the bottom of the page)
https://github.com/senchalabs/connect/blob/master/lib/middleware/session/memory.js
(the default memory store for session that connect has built-in)
https://github.com/senchalabs/connect/wiki (Session Stores)
From the Connect guide (Connect Session page):
Session Store Implementation
Every session store must implement the following methods
* .get(sid, callback)
* .set(sid, session, callback)
* .destroy(sid, callback)
Recommended methods include, but are not limited to:
* .length(callback)
* .clear(callback)
For an example implementation view the connect-redis repo.
* param Object options
* returns Function
All examples I find use different
kinds of NoSql-databases.
The nice thing about a lot of those NoSQL databases is that they are really easy to install. Installing redis is very easy and will make your site a lot faster(in memory database backupped by disc)...
Could anyone shed some light on where
to find other session store modules
I found the following modules using http://search.npmjs.org / http://github.com searches:
https://github.com/pkrumins/supermarket-cart
Supermarket-cart can be used to store
connect's sessions in supermarket
database.
I believe this uses sqlite.
http://search.npmjs.org/#/connect-cookie-session:
A Connect middleware to allow you to
store your sessions directly in the
client's cookie.
https://github.com/caolan/cookie-sessions
Secure cookie-based session middleware
for Connect.
https://github.com/creationix/nstore-session
This is a simple session store for
Connect that uses nStore for
persisting session data.
https://github.com/visionmedia/connect-redis
connect-redis is a Redis session store
backed by node_redis, and is insanely
fast :)
https://github.com/masylum/connect-mongodb
https://github.com/kcbanner/connect-mongo
This is what I found quickly, but when doing a more thoroughly search I believe you should be able to find even more session implementations.
or even how to implement one.
I think you should be able to use supermarket-cart, but you could also implement your own store by using this links as a reference:
http://senchalabs.github.com/connect/middleware-session.html
https://github.com/visionmedia/connect-redis
Related
In my Flutter/Dart mobile app I make use of Firebase RTDB persistence to enable offline use of the app.
My understanding is that to enable persistence you have to make the call, as per the following piece of code, before using any database references to eg. query the database. I use the following piece of code to enable persistence immediately after loading the app and it works fine:
FirebaseDatabase firebaseDatabase = FirebaseDatabase.instance;
bool _success = await firebaseDatabase.setPersistenceEnabled(true);
print(_success); // Prints true, so persistence is set 'on'.
When I logout of the app I attempt to turn persistence off with:
bool _success = await firebaseDatabase.setPersistenceEnabled(false);
print(_success); // Prints false, so persistence is still 'on', ie. the call failed.
I assume the reason persistence cannot be turned off is because there have been calls to db references prior to trying to switch it off.
This leads to three questions, I guess:
Should I be worried about turning it off at all, when I logout? The reason I attempt it is good house-keeping, mainly. I clean up shared preferences, close keepsyncd's, etc when logout is run. Also, though, the user can have multiple userids to login and I want to make sure that I am not retaining persisted data from their previous login id.
Related to 1, does setting persistence to false clear the cache of
data and potential queued calls to the db?
If the answers to 1 and 2 are 'yes', how can I switch persistence off given the code I'm using to do so keeps telling me it failed?
The typical way to handle this is to enable persistence once a user logs in.
Once disk persistence has been enabled and your app has used the database, it cannot be turned off. The documentation says this about it:
The returned Future will complete with true if the operation was successful or false if the persistence could not be set (because database references have already been created).
That last bit is clearly the case for you: you've been using the database already, which means that disk persistence is on.
To your specific questions:
Unfortunately the data in the local cache cannot be cleared up through the API at the moment. It is a valid feature request, but for now you'll have to assume that any data on the device can be seen by any user on that device (or device profile).
Disabling disk persistence keep the client from adding data to the cache. It does not clear any existing data in the cache.
I have a mobile service sync table that is giving me absolutely HORRENDOUS performance.
The table is declared as:
IMobileServiceSyncTable<Myclass> myclassTable;
this.client = new MobileServiceClient("my url here");
var store = new MobileServiceSQLiteStore(“localdb.db”);
store.DefineTable<Myclass>();
this.client.SyncContext.InitializeAsync(store);
this.myclassTable = client.GetSyncTable<Myclass>();
Than later in a button handler I’m calling into:
this.myclassTable.ToCollectionAsync();
The problem is, the performance is horrific. It takes at best minutes and most times just sits there indefinitely.
Is there anything in the above that I’ve done that would explain why performance is so absolutely terrible?
this.myclassTable.ToCollectionAsync();
For IMobileServiceSyncTable table, the above method would execute the SELECT * FROM [Myclass] sql statement against your local sqlite db.
The problem is, the performance is horrific. It takes at best minutes and most times just sits there indefinitely.
AFAIK, when working with offline sync, we may invoke the pull operation for retrieving a subset of the server data, then insert the retrieved data into the local store table. For await this.myclassTable.PullAsync(), it would send request and retrieve the server data with the MaxPageSize in 50, and the client SDK would send another request to confirm whether there has more data and pull them automatically.
In summary, I would recommend you checking with your code to locate the specific code which causes this poor performance. Also, you could leverage adding diagnostic logging, capturing the network traces via Fiddler to troubleshoot with this issue.
I have used the techniques in the RealmTask tutorial (https://realm.io/docs/tutorials/realmtasks/ ) to get a demonstration of synchronisation with the Realm Object Server working. However, as mentioned in realm mobile platform, how to connect while offline? , it is difficult to find design guidelines on realising a robust app in the presence of intermittent network connectivity. For example, the network might not be available when the app is first run, and in the tutorial example I think the login attempt would just time out after say 30 seconds.
From various sources, I have tried to outline an implementation approach on the client and have come up with the following:
=============================================================
At start-up of app
Create login credentials with
SyncCredentials.usernamePassword()
Check whether user credentials already exist using
SyncUser.all
If so, get the correct user using the appropriate key (UserId)
If a user is obtained, get the Realm configuration using
realmConfiguration = Realm.Configuration(SyncConfiguration(user, realmURL))
Attempt a log-in with
SyncUser.logIn with SyncCredentials
On completion, put the following on the main DispatchQueue (async)
realmConfiguration = Realm.Configuration(SyncConfiguration(user, realmURL))
if not logged in, repeat login attempts every N minutes until successful? E.g. to handle the situation when the network is unavailable when the app is started, but then becomes available?
Launch the rest of the app, making realmConfiguration available.
However, only access the Realm if realmConfiguration has been set up. Design the app so that it handles the scenario of realmConfiguration not being set up.
=============================================================
Is the above approach sensible, or is there a better solution?
Katsumi from Realm here. Our RealmTasks demo application may help you.
https://github.com/realm-demos/realm-tasks/tree/master/RealmTasks%20Apple
First, check whether the user has logged in or not at launched the app.
if configureDefaultRealm() {
window?.rootViewController = ContainerViewController()
window?.makeKeyAndVisible()
} else {
window?.rootViewController = UIViewController()
window?.makeKeyAndVisible()
logIn(animated: false)
}
https://github.com/realm-demos/realm-tasks/blob/master/RealmTasks%20Apple/RealmTasks%20iOS/AppDelegate.swift#L35
If the user has been logged in before, you can use user object that was cached before. (SyncUser.current or SyncUser.all)
If there is no cached user object (The user is the first time to use the app, or the user re-installs the app), show login view to signing up/in.
The former case (Use the cached user object) doesn't require network access, so you don't need to care about the offline situation.
The latter case (The user should signing up/in) requires network access, in that case, the best practice depends on the specification of the app. It is enough to show a just alert view that indicates requiring network for some apps, or use standalone Realm and then migrate synced realm after the app will be online.
I have been searching for an answer on MS, SE and Google and cannot find it. I want to use the GRS option for Azure Storage (Cloud Block Blobs) but I cannot figure out how to properly do that.
I created my storage object in Azure and chose the GRS option.
I get that I have a primary and secondary connection string and know how to get that from the Azure portal.
What I do not know, in ASP.NET 4.0, is how to set both connection strings in the CloudBlockClient and gracefully handle the primary storage being unavailable.
--What exception is thrown and where, when primary is unavailable? Is this thrown when I create the client, or when I try to get a blob reference?
-- How do I then use the secondary?
Do I have to just test for any old exception and then try using the secondary connection string in a new CloudBlockClient if the primary does not work? Or is there anything in the API for this. I would think there would be but I cannot find it.
None of the "How to use Azure Storage" tutorials I have seen go into this. Most of the documentation seems to date from before mid-2014 when this feature became generally available.
This blog post should help you. In short if you want to read from both primary and secondary you want to enable RA-GRS - essentially read access from the secondary. If you are using out storage client libraries you can also enable a retry policy that will first try to read from a primary and then from the secondary if the first read fails.
What's the standard way of storing user preferences in a Flex application for AIR? I need to store simple parameters like lists of recently opened files, window positions and sizes etc.
my favorite way to do it is to combine a VO with LSO (local shared object). If you have a LOT of settings, this doesn't work too well. The advantage is that you get a strongly typed settings object which is therfore bindable and has code introspection and completion.
The cool thing is it's only about 5 lines of code to manage an LSO. In addition, it's also pretty easy to manage a local encrypted store if you want to store any sensitive data.
registerClassAlias("SettingsVO",SettingsVO); //This lets us store a typed object in LSO
var settings:SettingsVO;
var settingsSO = SharedObject.getLocal("settings");
//Check to make sure settings exist... if not, create a new settings object
if( settingsSO.size && settingsSO.data && settingsSO.data.settings){
settings = settingsSO.data.settings as SettingsVO;
}else{
settings = new SettingsVO();
}
Now if you want to save settings you simply do
settings.someSetting = "newValue";
settingsSO.data.settings = settings;
settingsSO.flush();
And this solution works on BOTH AIR and Flex in any browser. Newer browsers will delete this data when clearing cookies, so beware of that.
I think the most flexible way is to use a local SQLite database. It gives you unlimited, structured storage and encryption if needed. See Peter Elst's introduction if you want to get more info.
There is no "Standard" way, but there are a lot of approaches, all which boil down to storing the user's preferences, then loading them up at runtime based on some uesr credentials, then changing the app based on those preferences.
You may store them in a server side database, such as SQL Server or MySQL; then have flex call a service which queries the database and returns the data.
You may store them as Shared Objects, which are the Flash version of browser cookies. (I believe they work on AIR applications too). This can get cumbersome with lots of data.
You may store them in an XML document and throw them on the server. Conceptually this is not much different than storing them in a server side database; but could get very tedious if you have a lot of users.
You could also store them, in an AIR app, locally using a SQLite database. SQLite is an embedded database used in Adobe AIR.
I don't bother with any of the fancy stuff. Just store it in an xml file in the application directory. Done.
Filestream does throw an error if you try to store it using File.applicationDirectory. I just trick the program...
var trickFile:File = File.applicationDirectory;
var file:File = new File(trickFile.nativePath + mySettings.xml);
Air falls for it every time.