Re: can_introspect_default feature

[Tim Graham]

Hi Maxi,

Did you take a look at the relevant commit that introduced the flag?
https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc

On Tuesday, October 18, 2016 at 9:51:46 AM UTC-4, Maximiliano Robaina wrote:
>
> Hi,
>
> How supposed to can_introspect_default must work?
>
> I'm working on django firebird backend and I'm trying to figured out how 
> this feature works, but the schema tests fails. 
> This default is at database level or django level?
>
> If I define a field with a default value, and do a metadata introspection 
> over this field to know if default value is defined, it always returns True.
>
> I hope be clear (sorry for my bad english)
>
> ---
> Maxi
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/05234368-c59e-4961-a98f-846716b410af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

can_introspect_default feature

[Maximiliano Robaina]

Hi,

How supposed to can_introspect_default must work?

I'm working on django firebird backend and I'm trying to figured out how 
this feature works, but the schema tests fails. 
This default is at database level or django level?

If I define a field with a default value, and do a metadata introspection 
over this field to know if default value is defined, it always returns True.

I hope be clear (sorry for my bad english)

---
Maxi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/24d65283-5bca-4253-8365-1f2b2d5a3307%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: LiveServerTestCase change in Django 1.11 means can't run functional tests against external server?

[Harry Percival]

Hi everyone, thanks for cc'ing me!

I'm relaxed about this -- my use of the --liveserver command-line arg was
always a hack, and i'm happy to figure out a different hack as and when i
come to update the book for 1.11.   A custom test runner that only does
FTs, and maybe hacks the class to no longer do the django stuff would
probably do it...

i wouldn't do anything special on my account.  do keep me posted if anyone
does decide to write their own hack and feels like sharing it tho!

hp

(PS not sure if i'm on the django-dev mailing list, do forward my email if
necessary)



On Mon, 17 Oct 2016 at 23:16 Tim Graham  wrote:

> Good points -- given the existing subclassing needed to get
> LiverServerTestCase to support that use case, it might be reasonable not to
> worry about backwards-compatibility here. I'd be interested to hear Harry's
> (the author) thoughts about it.
>
> On Sunday, October 16, 2016 at 1:44:02 PM UTC-4, Alex Riina wrote:
>
> Thanks for including a link to the TDD tutorial!
>
> As far as I can tell, the author wants to use `--liveserver` to point his
> functional tests at an external server so he can run his tests through
> nginx after running the same tests in his normal test environment. Based on
> the shell prompts in
> http://chimera.labs.oreilly.com/books/123400754/ch08.html#_creating_the_database_with_migrate
> I think he intends to have the database and code running on his staging
> server while he runs his tests locally. He also avoids the
> TransactionTestCase truncation operations by shorting out the
> LiveServerTestCase setUp / tearDownClass.
>
> Simplest way?
> The simplest way I can think of to resolve the issue is to read the
> external liveserver out of os.env instead of sys.argv. Then you can follow
> along exactly.
> $ export EXTERNAL_SERVER='http://superlists-staging.ottg.eu'
> $ python manage.py test
>
> `allow_database_queries = False` would make me trust the setUpClass /
> tearDownClass overrides more but my main issue with this approach is that
> it does a lot of extra work:
>
>1. run tests locally
>2. deploy to your code to your staging server
>3. runserver with fixed port on staging server
>4. run tests locally with LiveServerTestCases running against staging
>server
>
> It would be nice for the last run-through to _only_ run the functional
> tests and not have to setUp the local database or run the other tests
> against your local branch.
>
>
> Make unittest run functional tests remotely
>
> # app/test_functional_something.py
> import os
>
> if 'DJANGO_SETTINGS_MODULE' in os.env:
> from django.tests import StaticLiveServerTestCase
> FunctionalTest = StaticLiveServerTestCase
> else:
> class FunctionalTest(unittest.TestCase):
> live_server_url = 'http://superlists-staging.ottg.eu'
>
>
> then you can either run the tests via the DiscoveryRunner on the local
> database
> $ python manage.py test
>
> or via the normal unittest runner on your remote server
> $ python -m unittest discover -p 'test_functional_*.py'
>
> Unfortunately, you'll lose a lot of power in not being able to reuse your
> form code, assert anything about the database state on the remote server,
> access django assertion methods, ...
> At that point, I'd probably just run the tests on the remove server and do
> something like
>
>
> Hardcode the port
> class FixedPortServerThread(LiveServerThread):
> def _create_server(self, port):
>  if os.env.get('THROUGH_NGINX'):
>  return super(FixedPortServerThread, self)._create_server(port
> =8000)
>  else:
>  return super(FixedPortServerThread, self)._create_server(port
> =port)
>
>
> class MyLiveServerTestCase(LiveServerTestCase):
> server_thread_class = FixedPortServerThread
>
>
> On Saturday, October 15, 2016 at 9:32:54 AM UTC-4, Andrew Wall wrote:
>
> Very much appreciate the Django framework.
>
> I noticed in the docs
> 
> for Django 1.11 that the *DJANGO_LIVE_TEST_SERVER_ADDRESS* environmental
> variable is slated to be removed, along with the accompanying
> python manage.py test *--liveserver* option.  I'm concerned that without
> the ability to specify a remote IP address using --liveserver, it will no
> longer be possible to run functional tests using selenium against an
> external server.  I learned this technique from Harry Percival's excellent
> TDD with Python (see
> http://chimera.labs.oreilly.com/books/123400754/ch08.html#_configuring_domains_for_staging_and_live),
> where the test command is called from the local machine but you pass in the
> external IP.  Will there be a different way to do this in Django 1.11?
> Perhaps the change to bind LiveserverTestCase to port zero by default can
> be made while retaining the option to pass in --liveserver?  Realize the
> release is a ways away but would appreciate any help as I've come to rely
> on