thanks for everyone's input. I'll run parallel implementations and see
which one works best for the long haul.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Hi,
inspectdb makes step #1 much easier.
If you're not planning on removing some of the columns or restructuring
things, I'd recommend #1.
Collin
On Saturday, March 7, 2015 at 9:31:24 AM UTC-5, Derek wrote:
>
> I have taken route 1 before; its a bit more messy because you may have to
> expli
I have taken route 1 before; its a bit more messy because you may have to
explicitly map your desired model names to the actual column names. You
also face the issue of dealing with primary keys.
If you have the choice, and the current database is not in use anymore, I
would create a new one,
I'm not sure this is of help but I took was the easy way out. In my
models.py for each of my models.Model I added
Class Meta:
managed = False
That worked for me - the existing database tables were not touched.
Johnf
On 03/06/2015 01:18 PM, Robert Daniels wrote:
I understand it is possible
I understand it is possible to use an existing database on a new Django
project.
As I see it, I have 2 choices.
1 - Use the existing database and deal with it in that fashion.
or
2 - Create a new project to store the same type of data as if there were no
existing database, Then write a separ
5 matches
Mail list logo
