I am working on Magento 2 (ver. 2.4.3-p1) with theme Porto.
I have 2 instances of Megento. One is with database having all the product and site data and other is blank site (with no product / site data) but only frontend design implemented.
I want to merge both databases into one so the design and code becomes on 1 instance.
My questions is, which tables from "design instance" should be copied to "database instance" (having all the product and site data). I know the frontend files structure but need to know database tables involved in front end design.
Any help is highly appreciated
Related
I have been asked by a client to assist in making the web frontends of number of Lotus / IBM Notes databases, used for critical LOB functions, compatible with modern browsers.
As it stands, the web frontends of these databases only work in IE7, and even then they're temperamental at best. The JS uses IE-specific extensions, everything is in tables, and they render poorly on pretty much every browser available today. With IE7 no longer in support, they want to modernise these interfaces.
I have very little experience with Notes, but as an exploratory exercise I've managed to open up the databases in Domino Designer, add a few Stylesheet / Script resources, include them in the $$HTMLHead variable and reworked one Form to use a frontend framework, which looks good.
Obviously working on live applications is out of the question, so my thinking is to take a copy of the NSF files, and make the changes on the copies. My question is: how can I then deploy only the form / subform / resource changes to the 'live' NSF files?
Deployment:
In your new modified database :
You define in the Database properties that is a Database file is a master template (give a name)
In the production database :
first do a backup ! copy (only design) to a new copy of the prod
You define in the Database properties that it inherits from master template (same name)
on the prod make refresh design
more details : https://www.ibm.com/support/knowledgecenter/SSVRGU_9.0.1/com.ibm.designer.domino.main.doc/H_ABOUT_REFRESHING_A_DESIGN.html
Sorry to state the obvious, but since you have a Notes client and a Domino server, you have a quite extensive documentation at your disposal in the form of databases located in the /help/ directory. Make sure they are full-text-indexed.
And since we are on the subject of templates, Domino comes with a host of ready-made, ready-to-use apps that you can customize and canibalize. Look for discussion9.ntf for starters.
You may want to start here, then go there, and finally that will give you the keys to build word-class web apps on Domino.
Last thing, if you are on V9, the Designer help is crap. Grap a copy of the 8.5 version. Seriously.
If you want to build a modern web based front-end to existing Domino data, take a look at the following presentations:
http://www.slideshare.net/TexasSwede/ad102-break-out-of-the-box
and
http://www.slideshare.net/TexasSwede/break-out-of-the-box-part-2
As others already said, you should create a template and then just refresh/replace the design of the production database using that template.
You may want to consider working with an experienced Notes/Domino developer for that project, there are quite a few caveats and workarounds you need to know know about...
I'm starting a new project and I want to use AngularJS as Frontend and SailsJS as Backend. I have a requirement to separate databases for different clients. So, each client must have its own database.
I didn't find how to make this in Sails and Waterline. Does anybody know how to do this?
I have to change schema(or database) in runtime.
Right now, Sails does not have support for multi tenant databases.
It all depends also how many customers you have.
One approach that you can do (as with any other framework/language) is having (at least) one instance of your application pointing to different database configurations. Then have different domains for each customer. This involves creating a new "domain" per customer.
Another approach (that involves more coding) is to have the concept of an Organization entity that owns every object and include that on every filter.
There has been some PRs in the past about it but didn't move forward.
I have a design issue that i'm facing and because i am relatively new to mongodb i think i need some help to make the right decision.
problem:
i am building a type of social networking website for let's call group A consumers. I also need to build this same type of website for group B consumers. initially, i want to keep them separate with no interaction/sharing between the two groups but i do not want to maintain two separate websites. so a multi-tenant solution is ideal. the tricky part of this problem is that at SOME point in the future, i want to create a website for BOTH group B and A consumers, essentially merging them into 1 website. this 1 website will have all users from the original groups A and B but now they can all see each other, interact with each other, friend each other, etc.
is the right path to first create a multi-tenant mongo database, then later how easy is it to remove this multi-tenancy?
I would suggest that you do not create and drop the databases. Instead you can have the application with 2 tenants like facebook and g+ with their own set of users. However at some point of time in the future, you can just share your facebook user to g+ or the otherwise. in this case, there is no need to drop / merge tenant based tables or database and they will remain intact.
Your application should have the multi-tenancy capabilities that enable user sharing across tenants or linking users across tenants and that is the sure shot approach.
I have a desktop ERP application used by around 100 customers at different locations.Since its cumbersome to manage deployment and installation of such environment,i am planning to move this to web platform.I came accross this concept of software as service..I intend to go for this design approach...
The challenge i face here is that all customers will have there own databases and i want to make single web application which can connect to all the databases based on some licensing mechanism...
I am not quite sure how to do this.
Feedback and suggestions on this are most welcome.
The SaaS philosophy is building in two principles. Multi tenant principles and local tenant principles. At first you store user stuff in one database, for second user created new database, for third - created new database and etc. In local tenant option you store all data of all users in one database.
At first - you need a database storage (mysql,msslg, other with) , web aplication for use in browser (buld in php, or html5, of adobe flash(OMG!).
Web application conect with database - used permission for users and etc.
at simple thats all!
And a have a question in which for you ERP store a users,passwords,documents and other?
Depending on the answer, to look for a solution.
I have developed a number of departmental client-server applications, and am now ready to begin working on moving one of these applications to a SaaS model. I have done some basic web development, but I'm a newbie when it comes to SaaS architectures.
One of the first questions that comes to mind as I try to design the architecture is the question of single vs. multi tenancy. The pros and cons of each vary significantly depending on the type of application and scale required, so I'd like to describe my application and scale needs below, and hope others can comment on how I should get started with the architecture.
The client-server application currently consists of a Firebird database and a Windows application. The database contains about 20 tables containing a few thousand records in 4 primary tables, and a few hundred records in various lookup and related tables. Although the number of records is small, the size can get large, as the database can contain large BLOBS. Each customer sets up their own database and has a handful of users within the organization connected to it. When I update the db schema, a new windows application is released, and it checks the db schema and then applies the updates as needed.
For the SaaS application, I am designing for 100's (not 1000's or millions) of new customers per year. My first thought was to go with a multi tenancy model to make updates easy (shut down apply the updates to one database, and then start up). On the other hand, a single tenancy model would provide a means to roll updates out to a group of customers at a time, and spread the risk of data corruption - i.e. if something goes wrong with a database, it will impact one customer instead of all customers. With this idea, I was thinking of having a single web front-end which would connect to a single customer database upon login. Thus, when a new customer creates an account, a new database would be created (each customer would have their own db with multiple users as needed for the customer).
In this model, a db update would require either a process to go through each db to apply schema changes, or a trigger upon logging in to initiate a schema update similar to the client-server model currently in use.
Can anyone point me to information for similar applications which have been ported from client-server to SaaS? Or provide any pointers to consider? Basically I'm looking for architecture examples of taking a departmental application and making it available as a self service website for multiple customers. Thanks for any suggestions, resources, etc.
Good questions.
One thing that comes to mind is that if you have multiple databases which you roll out in a staged manner to reduce the likelihood of breaking all of your customers, you will have to address the issue of what to do if the db structure changes. You will either have to be very rigorous with respect to maintaining backward compatibility, or else deploy separate versions of your code base and somehow manage which tenants are associated with which databases.
We are providing our application using a SaaS model as well.
It was, initially a Windows app which worked similar to your multiple database proposal. Upon login, the win app would authenticate against a single "licensee" database which would then respond with connection information for a database specific to that licensee. The nice thing about this was that it provided 1) physical separation of licensee data, which our customers liked and 2) enabled us to physically locate the database on a server geographically closer to the users which both improves performance and avoids some potentially tricky legal and regulatory issues with respect to providing data across country boundaries.
Of course, since the app was a thick client app, we could get away with making database changes and pushing them out to one licensee at a time. When we were ready to upgrade, we could push out an updated thick client in conjunction with the new database - thereby ensuring that the codebase was a match with the database. As long as the common "licensee" authentication database stayed consistent, this worked fairly well.
On the other hand, though, this solution brought with it all of the problems of maintaining and managing a thick client approach which finally lead us down the thing client, browser-based approach.
In our new model, everything is in a single database. When we have updates, we push both the code and the db out at the same time. This solves the problem of keeping the code base consistent with the database structure. However, we are now confronted with the issues mentioned in #s 1 and 2, above, which we have yet to resolve.
I hope this provides some food for thought for you.
I, too, am interested in this question.
Thanks for the post.
-S