Is there a way to keep a design element (e.g View, Form, Agent...) in the template database and not refresh it to the inheritance database when I refresh design?
I have some views I want to delete from a database but keep them on the database template. I don't want them to "return" to the database after refresh design
Thanks,
Y
There is no way to prevent design elements from being inherited. I usually use another solution: Versioning.
Create a new copy of your template and give it another version in Title, Filename and Template name. Then remove the views from this new version and replace design of your database. That way you still have an "old" copy in the older template version.
The other advantage is: If something really goes wrong, you can switch back to the "older" version of the template at any time...
Related
This is actually the first time I'm posting something here. The problem I have is driving me crazy since I know such functionality exists elsewhere.
I'm trying to find a way to create new tables on the fly on node js using sequelize without having to restart the database (a DB implemented with SQL).
Moreover, I also need to create new associations between those new table and existing ones.
Why do I need this:
I'm creating a crm and one of the functionalities I want to add is to let users create new types of objects that could have fields referencing to other preexisting ones.
And I can't just restart the whole database everytime a user is creating a new object or fields.
If you guys know how to achieve that or maybe advising me to build the database with another language I'll go for it.
Thanks!
I want to store information in some activities that are modified versions of activities imported from an existing database (ecoinvent).
I know we can add fields to activities created from scratch (example). (I guess this is because the structure of the database has not yet been defined...) but is there a way of adding it to activities of an already defined database without breaking it?
The way around I found is to add entries to the author dict, which I can easily access later on. e.g.
act['author']['scenario']='myscenario'
but I admit it is not a very elegant solution.
You can just add whatever data you want. Brightway is a (semi-)schemaless database for exactly this reason.
act['foo'] = 'bar'
act.save()
I have a database called "development-records" that has a MapReduce view with a "dbcopy" declaration that creates a view in a new database called "development-chained".
When we make an update the view in "development-records", we do the usual steps of:
1. Create a duplicate copy of the design document that we want to change, for example by adding _OLD to its name: _design/fetch_OLD.
2. Put the new or 'incoming' design document into the database, using a name with the suffix _NEW: _design/fetch_NEW.
3. Query the fetch_NEW view, to ensure that it starts to build.
4. Poll the _active_tasks endpoint and wait until the index has finished building.
5. Put a duplicate copy of the new design document into _design/fetch.
6. Delete Design Document _design/fetch_NEW.
7. Delete Design Document _design/fetch_OLD.
The problem is that the documents specified in the dbcopy database "development-chained" don't seem to be updated -- all the old records stay. Is there a way to trigger the dbcopy database to perform the MapReduce again?
Unfortunately, according to the official Cloudant documentation, "The dbcopy feature can cause problems under some circumstances." Use of this feature is strongly discouraged, and has otherwise been removed from the documentation. I hope knowing that helps a little. The new documentation is hard to find.
I am looking at the documentation for Meteor and it gives a few examples. I'm a bit confused about two things: First, where do you build the db (keeping security in mind)? Do I keep it all in the server/private folder to restrict client-side access? And second, how do I define the structure? For example, the code they show:
Rooms = new Meteor.Collection("rooms");
Messages = new Meteor.Collection("messages");
Parties = new Meteor.Collection("parties");
Rooms.insert({name: "Conference Room A"});
var myRooms = Rooms.find({}).fetch();
Messages.insert({text: "Hello world", room: myRooms[0]._id});
Parties.insert({name: "Super Bowl Party"});
I don't understand how a collection's structure is defined. Are they just able to define a collection and throw arbitrary data into it?
To answer your first question about where to put the new Meteor.Collection statements, they should go in a .js file in a folder accessible by both client and server, such as /collections. (With some exceptions: any collections that are never synced to the client, like server logs, should be defined inside /server somewhere; and any local collections should be defined in client code.)
As for your second question about structure: MongoDB is a document database, which by definition has no structure. Per the docs:
A database holds a set of collections. A collection holds a set of
documents. A document is a set of key-value pairs. Documents have
dynamic schema. Dynamic schema means that documents in the same
collection do not need to have the same set of fields or structure,
and common fields in a collection’s documents may hold different types
of data.
You may also have heard this called NoSQL. Each document (record in SQL parlance) can have different fields. Hence, there's no place where you define initial structure for a collection; each document gets its "structure" defined when it's inserted or updated.
In practice, I like to create a block comment above each new Meteor.Collection statement explaining what I intend the structure to be for most or all documents in that collection, so I have something to refer to later on when I insert or update the collection's documents. But it's up to me in those insert or update functions to follow whatever structure I define for myself.
A good practice would probably be defining your collection on both client and server with a single bit of javascript code. In other words, put the following
MyCollection = new Meteor.Collection("rooms");
// ...
anywhere but neither in the client nor in the server directory. Note that this directive alone does not expose any sensitive data to nobody.
A brand new meteor project would contain by default the insecure and autopublish packages. The former will basically allow any client to alter your database in every possible way, i.e. insert, update and remove documents. The latter will make sure that all database content is published to everyone, no matter how ridiculously this may sound. But fear not! Their only goal is to simplify the development process at the very early stage. You should get rid of these to guys from your project as soon as you start considering security issues of any kind.
As soon as the insecure package is removed from your project you can control the database privileges by defining MyCollection.allow and MyCollection.deny rules. Please check the documentation for more details. The only thing I would like to mention here is that this code should probably be considered as a sensitive one, so I guess you should put it into your server directory.
Removing the autopublish package has effect on the set of data that will be sent to your clients. Again you can control it and define privilages of your choice by implementing a custom Meteor.publish routine. This is all documented here. Here, you have no option. The code can only run in the server environment, so the best choice would be to put it in the server directory.
About your second question. The whole buzz about NoSQL databases (like mongodb) is to put as few restrictions on the structure of your database as possible. In other words, how the collections are structured is only up to you. You don't have to define no models and you can change the structure of your documents (and or remove fields) any time you want. Doesn't it sound great? :)
We have a bunch of databases with similar designs. All of them have some design elements which inherit from various templates. Many of them have a specific view that needs that needs to be updated, but is not marked to inherit from a template.
While I know that I could remove the view from the databases, I'm not sure how I would add just that view from my template to each of the databases without doing it manually.
How would I copy a design element from one database to another programmatically?
I'm not sure why you cannot just mark also these views to inherit from template. Anyway Views are also notes and you should be able to copy a view this way:
lotus.domino.Database db = session.getCurrentDatabase();
db.getDocumentByUNID(db.getView("myview").getUniversalID()).copyToDatabase(dbTarget);
You can not copy the NotesView directly. But you can do it by DXLExporter and DXLImporter.
This is just complex and waste of time.
We have one alternate way for doing this. Instead of copying the view. We can copy the viewColumn and Create a new view in all other databases. Paste these column into it.
Set notesViewColumn = notesView.CopyColumn( sourceColumn [ , destinationIndex& ] )
I know that it does not answer exactly your questions but i wanted to suggest a Different approach.
You can have the view in the template and in all databases.
Then you could add an Option in a Profile to enable or disable the view.
In the outline you can hide or Display the view depending on the Profile setting.