As a webapp novice, I'm not sure if I need to define models.py.
I already have a working Postgres database on Heroku that I've linked up with Postico and pgAdmin. Using these GUIs, it seems I can get and post data, and make structure changes very simply.
Most tutorials seem to glaze over the details and reasoning for having a models.py. Thanks!
Web frameworks typically enforce or encourage a Model-View-Controller (MVC) patterns that structures code such that the database code is kept separate to the presentation layer.
Frameworks like django come with and are more integrated with ORM functionality which is used to implement an MVC framework. The ORM allows you to programatically interact with your database without having to write sql code. It can let you create a schema as well as interact with it by mapping programming classes to tables and objects to rows.
Flask can be distinguished from many other web frameworks, like django, in that it is considered a micro framework. It is light weight and can be extended by adding extensions. If you need the database integration then you can use it with an external ORM tool like sqlalchemy (and optionally flask-sqlalchemy extension). You can then define a sqlalchemy model, for instance, in a file called model.py or schema.py, or any other name you find appropriate.
If you only need to run one or two queries against an existing postgres database and feel you have no need for the use of an ORM, you can simply use flask with the postgres driver and write the sql yourself. It is not mandatory to have a model.
A model/ORM can be beneficial. For example if you want to recreate an integration/test instance of the database, you can instruct the ORM tool to create a new instance of the database on another host by deploying the model. A model also provides a programming abstraction to the database, which in theory should make your code more database independent (well in theory, its hard to achieve this as databases can have subtle differences), and should make your code less tied to a specific database solution. Also, it alleviates the need of writing a language within a language (sql text strings within python code).
Related
My company's main software application hasn't been updated in twenty years. I expect to soon be working on a complete rewrite of it. To that end, I am beginning to work my way through the book "Pro ASP.Net Core 3" by Adam Freeman (8th edition).
Our application was written to be independent of specific database types. Most of our customers use PostgreSQL, but a few use SQL Server. Therefore, we use ODBC because ODBC drivers exist for both of those databases, as well as several others. The application does not do anything fancy with the databases, and ODBC works well. We configure an ODBC DSN to talk to whichever database the customer has, and the application itself doesn't have to be changed.
A search on "Entity Framework Core ODBC" led me to the EF Core Github, where people have asked similar questions, and the answers were mostly along the lines of "why on earth would you want to do that?". Well, I need to do that.
Can I use EF Core with ODBC, or is there some other way that I can set up an Entity Framework Core application that does not have to be modified if the underlying database changes from PostgreSQL to SQL Server?
You could use your appsettings.json to store a value used to swap between the two. Those environment configs get reloaded on change (though you might have to restart your application to read them again, I'm not sure on that one).
Regardless something along the lines of this would suit your needs I think.
if (Configuration.GetSection("dbOptions")["postgres"]))
services.AddDbContext<ApplicationDbContext>(options => options.UseNpgsql(Configuration.GetConnectionString("PostgresConnectionString")));
else
services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("SqlServerConnectionString")));
EDIT: I placed this in Startup.cs where you would normally configure the DBContext. I use a similar solution reading off the Environment type to load either the Prod or QA connection strings based on deployment. In principle, this should accomplish the same task without the need for rebuilding and redeploying the code base.
We have a couple of large, mature apps installed in hundreds of medical clinics. These apps are built using Windows Forms and WPF and although we host the database for some of them, the majority of our clients have a local install of the database.
We are in the planning stages of rebuilding our application on the ASP.NET MVC platform using Entity Framework. We will also be re-architecting our database, but for reference, the current database has about 600 tables and 1900 stored procedures. Although we don't have an official DBA, we have enough DBA skills to build and maintain what we have, so we are capable of designing and building the data model ourselves. Also, we will continue to have both on-premise and hosted solutions.
Our struggle is with deciding how to use EF. We're all in agreement that we should use code-first, but some of us think we should build our classes, decorate them with attributes, and allow EF to generate the database for us. Others think we should design and build the database and then generate code-first POCOs.
Assuming we will have non-CRUD stored procs, triggers, views, stored procs, and user defined functions, is database generation a reasonable approach? Are there reasons why it might be the preferred approach? Any good reasons for avoiding it altogether?
I got an existing database with many tables which are accessed using stored procedures only (no O/RM). I'd like to create new tables in this database using Entity Framework and the Code First approach.
Do all the tables in my existing database need to be modelized in my Entity Framework classes? Will I be able to hand-code only the new classes I need in my DbContext? Other tables really need to stay untouched and away from O/RM for the moment.
Note: I'm going to be using the latest EF5.
As for now the Power Tools only allow you to reverse engineer all tables and views in the DB, which can be a problem if you have a big DB, with hundreds of objects, you do not want to reverse engineer.
However, I found an easy workaround for that:
Create a new technical user for the reverse engineering. To this user you only grant permission to the tables and views, that you want to be reverse engineered.
Have fun!
You are under no obligation to map any given table with EF. If you already have a database, you may want to consider reverse-engineering your database with the EF Power Tools available from Microsoft. I did this recently with a MySQL database that I had for testing purposes and it worked quite well!
If you are new to EF an advantage is that the PowerTools write a ton of code for you, which will help you get a grasp on the syntax of Code First. You will need to modify the output but it is a great start. I really believe that this approach will give you the least headache.
The EF PowerTools can be found here: http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d/
I recently started using RavenDb. I am converting a relational dbase to use RavenDb. I have two simple tables in the Relational dbase:
tbStates
tbCities
I have all US cities linked to a state. How can I go about converting this to no-sql. Will I have to write a little application to read from the relational dbase and create the objects? Or are there some tools out there I can use to do this?
There is a utility called smuger http://ravendb.net/documentation/smuggler but I imagine you will have to convert your data to Json. It may be just as easy to write a console app that reads the tables to objects then loads to Raven.
Just to add I migrated a SQL Server database to RavenDB using the console application route.
I used EF to quickly pull out the data and converted it to my RavenDB domain then added it to RavenDB.
It Worked well as you will most likely want to tweak the domain anyway to work best with RavenDB (For example I had an Images SQL table that I turned into a List on the document etc).
See Ayende's RacoonBlog project on github (https://github.com/ayende/RaccoonBlog) as he does something similar to move subtext data to RavenDB. RacoonBlog is the engine powering his blog and makes for good learning material about how to use RavenDB.
I've prototyped an iPhone app that uses (internally) SQLite as its data base. The intent was to ultimately have it communicate with a server via PHP, which would use MySQL as the back-end database.
I just discovered Google App Engine, however, but know very little about it. I think it'd be nice to use the Python interface to write to the data store - but I know very little about GQL's capability. I've basically written all the working database code using MySQL, testing internally on the iPhone with SQLite. Will GQL offer the same functionality that SQL can? I read on the site that it doesn't support join queries. Also is it truly relational?
Basically I guess my question is can an app that typically uses SQL backend work just as well with Google's App Engine, with GQL?
I hope that's clear... any guidance is great.
True, Google App Engine is a very cool product, but the datastore is a different beast than a regular mySQL database. That's not to say that what you need can't be done with the GAE datastore; however it may take some reworking on your end.
The most prominent different that you notice right off the start is that GAE uses an object-relational mapping for its data storage scheme. Essentially object graphs are persisted in the database, maintaining there attributes and relationships to other objects. In many cases ORM (object relational mappings) map fairly well on top of a relational database (this is how Hibernate works). The mapping is not perfect though and you will find that you need to make alterations to persist your data. Also, GAE has some unique contraints that complicate things a bit. One contraint that bothers me a lot is not being able to query for attribute paths: e.g. "select ... where dog.owner.name = 'bob' ". It is these rules that force you to read and understand how GAE data store works before you jump in.
I think GAE could work well in your situation. It just may take some time to understand ORM persistence in general, and GAE datastore in specifics.
GQL offers almost no functionality at all; it's only used for SELECT queries, and it only exists to make writing SELECT queries easier for SQL programmers. Behind the scenes, it converts your queries to db.Query objects.
The App Engine datastore isn't a relational database at all. You can do some stuff that looks relational, but my advice for anyone coming from an SQL background is to avoid GQL at all costs to avoid the trap of thinking the datastore is anything at all like an RDBMS, and to forget everything you know about database design. Specifically, if you're normalizing anything, you'll soon wish you hadn't.
I think this article should help you.
Summary: Cloud computing and software development for handheld devices are two very hot technologies that are increasingly being combined to create hybrid solutions. With this article, learn how to connect Google App Engine, Google's cloud computing offering, with the iPhone, Apple's mobile platform. You'll also see how to use the open source library, TouchEngine, to dynamically control application data on the iPhone by connecting to the App Engine cloud and caching that data for offline use.
That's a pretty generic question :)
Short answer: yes. It's going to involve some rethinking of your data model, but yes, changes are you can support it with the GAE Datastore API.
When you create your Python models (think of these as tables), you can certainly define references to other models (so now we have a foreign key). When you select this model, you'll get back the referencing models (pretty much like a join).
It'll most likely work, but it's not a drop in replacement for a mySQL server.