We have several teams working on different work packages involving same objects with single development server. My question: how can we mangae this kind of situations without losing the time of the resources. To elaborate more, I have two teams working on Account BC with different change orders with same release date and I want the work to be done in parallel. What are the best ways to handle this situation and my answer is we need to wait and not possible. Does any one have the solution to handle this situation?
Have both teams develop with an offline copy of the Accounts BC - sharing the object between themselves as a SIF file. Merge the two streams together with the Tools archive import function.
Create an new object manager for the server which has its srf point to one other than siebel_sia. Create as many users and mobile clients as the developers. Get them the extracted database on thier client names. Make on team work on main object manager (_enu) and get the other work on (_custom). Bouncing individual object managers as the development cycle continues
Related
I have a Django project representing an abstract retail store. Let's say it's deployed on a server and is available in the local network. I want to write another program (or extend this one?) to generate a bunch of Users, automate the process of signing up and logging in and automate their interaction with the system: make them interact with the system to order goods. So it's not just unit testing of my system but rather demonstration of how it works in real life. And I want to spawn many users to see how my system can handle many requests at once.
Is there some kind of framework for that? How would you implement this? Thanks.
There are plenty of software available for this specific need.
https://jmeter.apache.org/
https://www.cypress.io/
https://www.browserstack.com/selenium#:~:text=Selenium%20is%20an%20open%2Dsource,%2C%20and%20C%23%2C%20among%20others.
Go through these, hope you will find your solution
I've read articles and posts about what a project and an app is for Django, and basically end up using the typical example of Pool and Users, however a real program generally use a complex relational database, therefore its design gravitates around this RDB; and the eternal conflict raises once again about: which ones to consider an application and which one to consider components of that application?
Let's take as an example this RDB (courtesy of Visual Paradigm):
I could consider the whole set as an application or to consider every entity as an application, the outlook looks gray. The only thing I'm sure is about this:
$ django-admin startproject movie_rental
So I wish to learn from the expertise of all of you: What approach (not necessarily those mentioned before) would you use to create applications based on this RDB for a Django project?
Thanks in advance.
PS1: MORE DETAILS RELATED ABOUT MY REQUEST
When programming something I follow this steps:
Understand the context what you are going to program about,
Identify the main actors and objects in this context,
If needed, make an UML diagram,
Design a solid-relational-database diagram, (solid=constraints, triggers, procedures, etc.)
Create the relational database,
Start coding... suffer and enjoy
When I learn something new I hope they follow these same steps to understand where they want to go with their actions.
When reading articles and posts (and viewing videos), almost all of them omit the steps 1 to 5 (because they choose simple demo apps), and when programming they take the easy route, and don't show other situations or the many supposed features that Django offers (reusability, pluggability, etc).
When doing this request, I wish to know what criteria is used for experienced programmers in Django to determine what applications to create based on this sample RDB diagram.
With the (2) answers obtained so far, "application" for...
brandonris1 is about features/services
Jeff Hui is about implementing entities of a DB
James Bennett is about every action on a object, he likes doing a lot of apps
Conclusion so far: Django application is a personal creed.
My initial request was about creating applications, but as models are mentioned, I have this another question: is with a legacy relational database (as showed in the picture) possible to create a Django project with multiple apps? this is because in every Django demo project showed, every app created has a model with their own tables, giving the impression that tables do not interact with those of other applications.
I hope my request is more clear. Thanks again for your help.
It seems you are trying to decide between building a single monolithic application vs microservices. Both approaches have their pros and cons.
For example, a single monolithic application is a good solution if you have a small amount of support resources and do not need to be able to develop new features in fast sprints across the different areas of the application (i.e. Film Management Features vs Staff Management Features)
One major downside to large monolithic applications is that eventually their feature sets grow too large and with each new feature, you have a significant amount of regression testing which will need to be done to ensure there aren't any negative repercussions in other areas of the application.
Your other option is to go with a microservice strategy. In this case, you would divide these entities amongst a series of smaller services and provide them each methods to integrate/communicate with each other (APIs).
Example:
- Film Service
- Customer Service
- Staff Service
The benefits of this approach is it allows you to separate capabilities and features by specific service areas thus reducing risk and regression testing across the application when new features are deployed or there is a catastrophic issue (i.e. DB goes down).
The downside to this approach is that under true microservice architecture, all resources are separated therefore you need to have unique resources (ie Databases, servers) for each service thus increasing your operating cost.
Either of these options is a good option but is totally dependent on your support model and expected volumes. Hope this helps.
ADDITIONAL DETAIL:
After reading through your additional details, since this DB already exists and my assumption is that you cannot migrate it, you still have the same choice as to whether or not you follow a monolithic application or a microservices architecture.
For both approaches, you would need to connect your django webapp the the specific DB you are already using. I can't speak for every connector out there but I know that the MySQL connector allows django to read from the pre-existing db to systematically generate the models.py file for the application. As a part of that connector, there is a model variable which allows you to define whether or not Django is responsible for actually managing the DB tables themselves.
The only thing this changes from an architecture perspective is how many times do you want to code this connection?
If you only want to do it once and completely comply with the DRY method, you can build a monolithic application knowing that as new features become required, application wide regression testing will be an absolute requirement.
If you want ultimate flexibility for future changes with this collection of features and don't mind recoding the migration across multiple apps while reducing the need for application wide regression testing as new features become required, a microservice architecture strategy is more appropriate.
We've lots of intranet projects written in Django. As projects grows auth is always painful and duplicated.
E.g. user needs to login to three internal systems:
http://192.168.x.x/proj1/
http://192.168.x.x/proj2/
http://192.168.x.x/proj3/
Basically he has to create three accounts on three systems. So I figured if the MySQL table auth_user and django_session could be shared (using MySQL federated table engine) across three django projects, login session and info could be shared. So create account once and login one and use all three systems.
Is it safe? Anyone done similar in practice?
Sharing auth and session tables is quite an acceptable solution as long as maintainers of each project are aware of this architecture.
Some issues to be aware of:
Each project needs to be aware of the data stored in session by the other projects in order not to overwrite it inadvertently. This is not an issue if you only use the session for authentication.
The messages framework will not work as expected. Again, this might not be an issue in your projects.
It's probably a good idea to use the same Django version across all projects. For example, Django 1.6 changed the way it stores sessions by default. The User model might also change between versions.
If you want to use a Custom User Model, you need to use the same model on all projects. This might be a good option if you need to share extra profile data across projects though.
Since all three projects will have access to the DB, you'd better consider those as a single project/entity from a security point of view. Some data may leak from one project to the other through the session and be exposed where it shouldn't.
Also, some security issues may arise: if for example two projects use inadvertently the same variable name to store conflicting data, considered safe by one project but unsafe by another, a user could inject malicious data which will be considered safe.
But these things could happen if you have a single project maintained by multiple programmers too. So, as long as you make sure these are not issues for your projects you should be fine.
I need to design and implement a Java web application that can be used by multiple users at the same time. The data that is handled by this application is going to be huge and may take about 5 minutes for a page to display the results(database records).
I had designed this application using HTML, Servlets and JSP. But when two users would try to get the records, only one user was able to view the results while the other faced an error.
I always thought a web application would take care of handling multiple users but this is not the case.
Any insights on this would be highly appreciated.
Thanks.
I always thought a web application would take care of handling multiple users but this is not the case.
They do if they're written correctly. Obviously yours is not. That's all we can tell you unless you give more information, most importantly details of the error shown to the second user.
One possibility is that everything is OK on the web layer but your DB access for the first user causes an exclusive lock so that the second user cannot access the data at the same time. This could be fixed by using non-exclusive read locks. How to do that depends mainly on what DB you're using.
Getting concurrency right requires you to choose the correct tools and use them correctly. It doesn't just happen magically because it's a web app.
What are are using to develop this web-application? If you are developing it in your own way from the start I must say you are trying to re-invent the same wheel which has been already created and enhanced by very solid frameworks.
I suggest you analyze your requirements thoroughly and study some available frameworks. Let them handle the things like multi threading and other aspects in the best possible manner.
Handling multiple request at a time is a container work and as an application developer we have to concentrate how we are handling and processing those requret being forwarded by the container.
I must suggest you to get some insight how web-application work and how request -response cycle happens
I'm working on a subset of my projects functionality, and I'm trying to focus on breaking my project into focused apps (as opposed to one monolithic app that does it all). After some googling, I want to keep each app tight and focused. However, I'm not exactly sure of the best way to divide up my code.
The overall functionality has three basic components:
Employees and their associated information.
Certificates/employee training and certificate information. Basically different types of training employees can receive and associated information.
Employee certifications (this links certificates to employees).
I have three main models: Employee, Certificate and Certification (which shares a relationship with both Employees and Certificates).
I could throw all three into a single app, as all three objectives are somewhat related, or, I could divide up the work. In the latter, two of the three are easy: employees and certificates can both exist without the other and have their own app, but certificates I'm not so sure about.
I could:
Bundle certifications in the employee or certificate app
Give certifications their own app
What say you? Does this scenario warrant more than one app? And if so, how should the three functionality requirements be divided up to keep each one tight and focused?
I would keep them all in a single app. It's too simple of an app (personally) for me to break it up. I would take advantage of django.contrib.auth.models.Users and build off of that in a structure which looks like this.
To take advantage of the users structure you need to extend the User model. Stackoverflow answers here and official documentation here.
HTH
I would advice to keep them in a single app : so all your models go into a single models.py,
and rather have multiple views.py (say for every functional unit).
This way, you can manage your models easily and also hit the right views file as required.
Keeping in multiple apps in this case would be an overkill, as there is no clear demarcation between the functionalities.