Re: re-apply migrations on restored database

Hey Hector,

There is a database table called "django_migrations" that is used to keep track of the applied migrations. I guess it's not documented, because touching it shouldn't ever be necessary.

It would be interesting to see how you ended up in a state that Django thinks all migrations have been applied, though.

/Markus

On October 30, 2014 7:07:02 PM CET, "Héctor Urbina" <hurbinas@gmail.com> wrote:

Hello,

I'm working on a development branch for a django (1.7) project. I have a couple of migrations, including a data migration, in this branch; and I already applied the migrations. After that, I took a dump of the production database (which didn't have those migrations, of course) and restored it to use in development. So, first thing I need to do is to re-apply all the development migrations to the database "again", but django says "no migrations to apply".

I can't find in the documentation how is that django knows what migrations have been applied so far, or if there is a way of changing that, in order to re-apply them.

Any help would be appreciated,

Hector.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

re-apply migrations on restored database

Hello,

I'm working on a development branch for a django (1.7) project. I have a couple of migrations, including a data migration, in this branch; and I already applied the migrations. After that, I took a dump of the production database (which didn't have those migrations, of course) and restored it to use in development. So, first thing I need to do is to re-apply all the development migrations to the database "again", but django says "no migrations to apply".

I can't find in the documentation how is that django knows what migrations have been applied so far, or if there is a way of changing that, in order to re-apply them.

Any help would be appreciated,

Hector.

--

Héctor Urbina S.
Ingeniero en Bioinformática
Fono: 82049138

--
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 django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CADHcORjtM2ywhbMGZWDrsatReCz1_H76JrX_axo6mysTL-xH2Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DB foreign key constraints : Django 1.7 regression ?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJUUnURAAoJEC0ft5FqUuEhXe0P/3oV+NGzoP+Sd+Ylm+K84eNg
2fSqkMTDDy//Q2ZFOkPoppubnjWaS+dxlXbOXlKkw9LVt1r4/5y6dneieEyktm4i
PdsTGJNU+lgY54MjOXRf98cfhNaDENi7kALiKdkcDYofLY/wnmzPicSaEtwEOQ09
yb1v2+ke31ZrINS22FujV2drXqPYgu56yJp1E2SllKeA71sDCf9RvppXNYRVVUgi
QdSJknVYlKRRlRpohOMkOmrI1C4dGySFq9DoNC/l9Yh2eg1hB25FI0y5z/lqd0hc
qJgVCgX6NBeP2cwGIhZ+G0bcVtMmtWUzXoBtpEHzRdAurnh42ca6Yq0/Af1wF5zr
vjOkPgZbmTKi6Mh9PPseDhKgUe3ZjYee8hfV/Ag9JULkDY53If+KgAisK4WggnDA
YdI8GhPeiIIOMDsvFDsA4S71zi8MewXcEYRczOgLMuJFfXF0zul9n5gmWjHYWgVH
M7tSpJ1TF6fKyqMT47m9refb+ldJTfgkkubv94EKbKPZs6QWoD/3wg9JIR4Ri5AR
fRow60LKKQBhJm7zK1+31uzzrSnTPuGuFVlk/duDkYzYZxWvdF/yyIEIk4XjPAao
LajlAVlsK5QS/COu+fWyZdTJXwXFN0p1IJM1acnu+aX1oJ+9b1L+7j+Ku4SoaNad
AFGcVf+V6BYYUe5mhwIy
=Idx6
-----END PGP SIGNATURE-----
On 10/30/2014 06:09 AM, notsqrt@gmail.com wrote:
> Thanks Daniel, that was it (instead of removing the migrations folder, I
> now use makemigrations).
>
> I expected everything to work without the need of migrations.
> So I guess that with django 1.7, it is simply mandatory to use migrations.
>
> It is indeed stated
> in https://docs.djangoproject.com/en/1.7/topics/migrations/#unmigrated-dependencies
>
> I guess adding a nice big system check would have helped me !
> Is that addition worthy of a ticket ?

I'm not sure off the top of my head how feasible such a check would be,
but in principle I think it would be a good idea - so yes, I'd recommend
opening a ticket.

Carl

Re: Do you think Django's future is threatened by JS frameworks in both client & server?

On Thu, Oct 30, 2014 at 2:54 PM, bobhaugen <bob.haugen@gmail.com> wrote:
> On Wednesday, October 29, 2014 12:26:01 PM UTC-5, Chris Hawkes wrote:
>>
>> All this being said, there is definitely a trend towards SPA's.
>>
>
> Does anybody else besides me hate the SPA trend? I much prefer apps that
> are separated into logical components where each component has its own URL,
> rather than an a seemingly-infinite scroll.
>

SPAs can (should) be separated into logical components that have their
own URLs - the fact that those distinct URLs load an SPA in to
specific states is desirable.

The trouble with SPAs is that people get tempted to do "un-webby"
things - SOLR's web interface springs to mind, the "application"
regularly polls the server to see if it is still there. If it is not,
it shades the page, making everything on the page unselectable and
says "instance gone away". All you can do then is reload the page when
it comes back, which loses anything input to that page.

OTOH, gmail is a SPA with deep links that work correctly and don't
ever cause problems. It does paging instead of infinite scroll.

Cheers

Tom

--
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 django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFHbX1JwEtY1odiyuiXu8e_bexpNzF43MDeUM-e4e8Uued%3DnsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Calling a function for a url tag parameter

Hi,

I am trying to use the url tag on some parameters, one of which needs to come from a function.

For example as follows:

{% with state_url=encode_url flow.state.description %}

<a href="{% url 'advance-flow' flow.id state_url %}">advance</a>

encode_url is defined as follows:

@register.simple_tag

def encode_url(link_text):

    return link_text.replace(' ', '_')

This causes an error on the with statement:

Request Method: GET

Request URL: http://127.0.0.1:8000/list_flows/

Django Version: 1.7

Exception Type: TemplateSyntaxError

Exception Value:

'with' received an invalid token: 'flow.state.description'

I'm guessing that you cannot put another template tag in the "with" statement.  I cannot see a way around this.  Any ideas?

Thanks

--
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 django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/9a93cbaf-0f47-41d5-9eea-e6d3297caeac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: pycurl and SSLv3

> Den 30/10/2014 kl. 15.50 skrev john <johnf@jfcomputer.com>:
>
> On the server side of my Django website I use pycurl (version 7.20.x) to connect to authorize.net (to send credit card info). On Nov 4 Authorize.net will turn off SSLv3. So I'm wondering if my use pycurl will continue to work. To be honest I haven't thought about it much since the pycurl seem to take care of everything that Authorize.net required. Now I'm questioning if pycurl will continue to work and if I need to change anything - what do I chan.
>
> c=pycurl.Curl()
> c.setopt(c.URL, GatewayURL)
> c.setopt(c.POST, TRUE)
> c.setopt(c.SSL_VERIFYPEER, FALSE)


This would depend on the version of libcurl on your server, and ultimately on the version of libssl.

I assume authorize.net will only accept TLS, so just force the SSL version and test if it works. Something like this should do:

c.setopt(c.SSLVERSION, c.CURL_SSLVERSION_TLSv1_2)


Erik

--
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 django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/D25E117E-82AF-4076-86AE-342FC7FD2571%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Do you think Django's future is threatened by JS frameworks in both client & server?

On Wednesday, October 29, 2014 12:26:01 PM UTC-5, Chris Hawkes wrote:

All this being said, there is definitely a trend towards SPA's.  

Does anybody else besides me hate the SPA trend?  I much prefer apps that are separated into logical components where each component has its own URL, rather than an a seemingly-infinite scroll.

--
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 django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/89172ae2-33de-4b36-8c36-d579fc31c8c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.