So we've starting using couchdb at work. Writing javascript functions in futon is no fun. I want to be able to write them in a text editor. I'd also like to be able to easily write my functions, push them to a dev database, and then push them to test/prod. Help?!
http://couchapp.org
Even if you aren't creating a typical couchapp (a web application served from CouchDB), I've found it to be a useful tool for the needs you describe.
A minimal couchapp allows you to organize each of your view, list, show, filter, and update functions as their own .js file, in a directory structure that makes sense. It takes care of JSON-encoding during a push, and assembling all of the files into a _design document. This allows you to easily use typical version control practices. It also supports other SCM practices, like enabling configurations for pushing to different environments. This avoids most of the hassles of Futon, which is not a very practical tool for managing your JavaScript functions in CouchDB.
Related
I'm currently trying to develop a reusable Yesod subsite to deal with user to user messaging. Ideally, the user should be able to download this package from Hackage, provide some hooks in their application, and have a modern, feature-ful messaging system on their Yesod master site.
However, I can't find any examples of a subsite that references the master site's entities. In this case, I'd like to build Persistent models for Messages that might reference a User from the master site.
None of the Yesod subsite tutorials I've found so far deal with using Persistent in a subsite.
The yesod-comments package is the closest thing I've found to what I'd like to build, but I'm a bit confused by the approach it takes.
Firstly, it seems to use strings to identify users, rather than the user's id directly, which seems inefficient.
Additionally, it seems to require a strange structure of callbacks (the persistStorage structure) in order to support comment storage, but this seems strange to me. It seems to me that, in Haskell, all the information necessary for figuring out which function to invoke should be done at the class and instance level, but in this case, I'm relying on passing around a bunch of callbacks in order for my code to work properly.
So here's a question to the Yesod community: what's the best way to develop these sorts of generic subsites in Yesod?
I'd really love to use Yesod in my projects, because I love Haskell and all the things that type-safety and static compilation brings (not to mention the speed and scalability benefits), but I can't help but feel pulled towards the dynamic frameworks, like Django and Rails, where not only is there an ecosystem to build and distribute reusable components, but also all the in-library infrastructure to build those components.
Have a look at how yesod-auth is implemented. Essentially, there's the YesodAuth typeclass that defines the various database operations that need to be provided, but doesn't actually implement them. The user of your subsite can then implement them, and at the same time has the flexibility to modify the database schema however he/she needs.
If in your case schema modification isn't strictly necessary, you can turn down the flexibility and simply require the user to use your data types in the database. If you want to go even further, you can just make the persistent calls yourself in your subsite, likely with something like:
lift $ get404 userId
If you're running into concrete issues with doing something like that, please provide the code and error messages so the problem is clearer.
I'd like to just use .json files to store data, rather than using a database. Many simple sites have little data, and reading/writing to a file (that can be added to version control) seems adequate, and eliminates the need for database versioning / deployment logistics.
npm: node-store
Here's one way to do it, yet I'd need to implement all kinds of query functionality.
I'm really unfamiliar with CouchDB. From the little I've read, it looks like it might use files to store the JSON data, but it might use some kind of disk storage. Can someone shed some light on this?
Does CouchDB store its JSON in text-based files that can be added to version control (git)?
Does anyone know of another text-based storage system with some query functionality?
CouchDB is a full fledged database. The value that gives you above simply using file based storage is additional indexing. Ie., if you do file based then you can either only do key based look ups (the file name) or build your own secondary indexing methodology (symlinks or whatever). Now you're in the database building business instead of the app building business, which is silly because your entire premise seems to be simplicity and focusing on your app.
Also, keep in mind that when you have many (even just 2) people causing writes to your file(s), then you're going to run into either file system locking problems or users overwriting one another.
You're correct though, if you only have a few pieces of information then a single JSON file - basically a config file - is far easier than a database. Especially if people are only reading from the file.
Also, keep in mind that there are Database-as-a-Service solutions that remove the need for DIY install/configure/maintenance/administration. One of them is Cloudant which is based on CouchDB, is API compatible, contributes back, etc. (I work at Cloudant).
Does anyone know of another text-based storage system with some query functionality?
You can use ueberDB module with Dirty file storage.
As far as I remember, this storage just appends your data to the same text file over and over again, so if you really have small dataset, it'll work just fine.
If you data will grow too much, you can always change storage while using the same module.
I'm planing on having my database stored in Cloudant.
Is it safe to use local CouchDB during development, testing and staging of our application with knowledge that everything works locally should also work on Cloudant?
Certainly. Cloudant is API compatible with the Apache CouchDB API with a few subtle distinctions, all of which are documented at http://docs.cloudant.com. Some highlights are:
we disable temporary views (they would be expensive for you at scale!)
for our distributed system, we have extend the update_seq from an integer to a string
your re-reduce code will nearly always be called, so we recommend using exclusively built-in reduce methods
we have fully integrated lucence indexing/search
we have multi-stage mapreduce processing via "dbcopy"
I do a very similar process. You don't need the same versions, it will actually be very different no matter how you look at it. Cloudant is very cool, and have made a lot of alterations and additions to their system. So, if you are looking at developing views, attachments, etc, then you can develop those locally on your dev project. Once your dev project looks good, I would have those checked into the staging/qa server, which I like to use Cloudant for as well. Thats where you need to get everyones code working together. after that is done, you can fire off a replicator to replicate your staging to production.
No matter how you look at it though, or how you envision the process being, you are going to want to take a close look at the going from dev to QA. There are ways to go about it so that everyone can dev on their own, and merge up. I personally like to use github. I hope this helps you out in your tasks.
Ok, here's the thing.
I have a good JS background, had my share of JS in the past, and have lots of cool bare-bones tools I take with me from project to project that act like a library.
I'm trying to formulate work with CouchDB.
Now, after getting used to luxury of cool tools that you wrote and simplify the language for you - I find it a little frustrating to write many things in bare-bones manner.
I'm looking for a way I can load to the database context a limited, highly efficient and generic set of tools that focus on the pure language and makes the work with the language much more groovy (and gosh, no, im not talking about jquery or any of the even more busty libraries out there).
If on top of that, there could be found a way where I can add to the execution context of the couchDB JS engine some of my own logic tools (BL model functions) - it would present a great and admirable power and make couchDB the new home for a JavaScript-er like me.
Maybe I'm aiming too low.
I'd be satisfied with a way I can allocate a set of extensions even for a specific database, and I don't mind do it for every database in separate. Or worse - to add it to every design document, so I can teach for example several views in the same design-doc what a Person is, what a Worker is, and use their methods to retrieve data from them according to logic in a reusably coded manner.
Can anybody point me the the way?
Whatever way you can point me - I'll be very verrry grateful.
If there are ways for all of these - then great.
Trust me to know the difference of what logic belongs to what layer...
You open my possibilities - I promise to use them :D
CouchDB now supports code sharing as CommonJS modules.
http://docs.couchbase.org/couchdb-release-1.1/index.html#couchdb-release-1.1-commonjs
http://caolanmcmahon.com/posts/commonjs_modules_in_couchdb
In this way, you can share your javascript modules between views, lists, and shows in the same design doc. (Server-side)
Also, you can load these modules on the browser side with this library:
https://github.com/couchapp/couchapp/blob/master/couchapp/templates/vendor/couchapp/_attachments/jquery.couch.app.js
You also might want to look at Kanso:
http://kansojs.org/
It does a really good job of making your javascript work seemless between the server and client.
You can find some helpful tools here : https://github.com/vivekpathak/casters
The running examples and test cases may particularly help you.
Is it possible to create a LotusScript library in one database and then access it from another database?
Without simply copying the library into each database that needs to use it.
What I would like to achieve is a single location where I can update the library and not have to manually copy it over to each database that is using it. I can't use a design template as the databases that use this script library all use different design templates.
I guess another solution would be to create an agent to copy the library out to all databases whenever it is updated. So if anyone has done anything like that before then I would also like to here about it.
Design inheritance in Lotus Notes isn't only on database level - individual design elements (such as your script library) can be explicitly inherited from a different template. See Linking individual design elements to a template.
With inheritance set up like this, the designer task on the Domino server will update the design element automatically. For this to work, the templates must be replicated to the same server.
You might want to disable this inheritance when you release your template, to avoid nasty surprises in the production environment. I created a solution for this a while ago: Remove Lotus Notes design element inheritance programatically.
Anders has answered the question very well. As Anders has already said, Domino, unfortunately, cannot share code libraries between databases. All the code is self contained, which is in this scenario a limitation.
Copying the agent into all the databases you want to use it for, and then employing design inheritance is a quick and easy way to distribute the agent.
An alternative idea, is to have a single database that serves as a repository of agents, so if you need to re-use the same agent over and over, it's design is always in one database, but you will need to design it so that it can perform operations on all the database you need to update.
Effectively, using each database as a datasource only, and the relevant agent(s) operating from one location. It will require some more work that will allow you to define some additional configuration documents that the agent(s) would use to identify which databases you want the agent to run on.
The advantages of this approach are :
You don't need to contend with design inheritance. It can get messy on a large scale when you have complex script library/design structures, you may have to buy third party tools to help you do this.
You can actually control which databases get updated via a series of configuration documents centrally with an "active/inactive" field that flags the database for update. Rather than directly "touching" the agents which requires you to get your hands dirty with enabling/disabling the agent. In some corporate environments which are tightly controlled, you need to keep asking the Notes admin to do this for you.
You can code the agent so that it reports activity in your own custom log documents when it runs on each database, and centrally store it.
Hope this provides you with some options...
You can share a lotusScript library between databases. export the script to a file with the suffix .lss and place it on the domino server in the domino folder. Then you can write "use "script.lss" " as with normal LotusScript libraries. You can see in the domino folder there are already some libraries eg. lsconst.lss