Re: Adding ability to choose AutoField type (signed vs unsigned)

[Tim Graham]

How would the strategy of having a setting generate new migrations work 
with third-party apps? Generally migrations can't easily be added to them 
by user projects and if more migrations are added to the third party app in 
a later version, there will be an inconsistent history.

On Thursday, April 9, 2020 at 3:06:51 PM UTC-4, Collin Anderson wrote:
>
> Having a DEFAULT_AUTOFIELD setting makes sense to me.
>
> On Monday, April 6, 2020 at 12:48:10 PM UTC-4, Adam Johnson wrote:
>>
>> Jure - yes switching the setting should generate migrations for all 
>> affected models. The migration guide would cover changing models' primary 
>> key fields to PositiveBigAutoFields one at a time, perhaps with a mixin as 
>> you've suggested. Maybe Django should provide such a mixin to ease the 
>> migration.
>>
>> primary keys might be GUID
>>>
>>
>> The proposal is not to move to GUID's/UUID's, as you've used in your 
>> example. It's to move to bigger integers.
>>
>> UUID's are a bad idea for database performance, as they distribute 
>> randomly across the table, preventing any cache wins. On autoincrement 
>> tables, the tail end of each table is normally most frequently read and 
>> written and thus cached in memory. I don't think Django should ever suggest 
>> UUID's as primary keys.
>>
>> On Mon, 6 Apr 2020 at 16:46, Jure Erznožnik  wrote:
>>
>>> Sorry if I understand stuff incorrectly, but:
>>>
>>> I agree with Adam where he discusses migration issues, but I also don't 
>>> see how "DEFAULT_AUTOFIELD" setting could leave tables out of the 
>>> migration(s). 
>>>
>>> My understanding is that it would cause immediate re-provisioning of all 
>>> the pk fields, including in the core django modules and third-party 
>>> modules. Some of them might have programmed their logic such as to include 
>>> some integer math around the primary keys (and now all auto primary keys 
>>> might be GUID).
>>>
>>> If I understand the above correctly, the setting would have to be 
>>> per-module. Could it simply be done like this:
>>>
>>> class PKMixin(object):id = models.UUIDField(primary_key=True, )
>>>
>>> Naturally, then all desired models would (also) derive from this mixin. 
>>> A bit of a chore, but it would not require reconfiguration of all 
>>> migrations, just the ones the programmer would specify - and would only be 
>>> limited to their own module.
>>>
>>> OTOH, JUST FOR the unsigned vs signed integer PK, it should be 
>>> relatively easy to modify makemigrations code detect existing migrations 
>>> for the model, detect that the only difference is IntegerField vs 
>>> PositiveIntegerField and in this case skip generating the migration (for 
>>> migrating the field to an unsigned one). There could also be a flag to the 
>>> management command specifying to force generating said migrations.
>>>
>>> Of course, ignore if this is gibberish.
>>>
>>> LP,
>>> Jure
>>>
>>>
>>> On 06/04/2020 17:11, Adam Johnson wrote:
>>>
>>> I'm in favour of the move. The setting strategy seems appropriate.
>>>
>>> Simon's comment on the PR that this affects a small % of projects is 
>>> true. But if your project does reach that scale, you're probably one of the 
>>> bigger Django organizations in the world - hopefully key advocates for the 
>>> framework. It's also possible to hit this on smaller projects with tables 
>>> that import a lot of new rows, such as rolling time series data imports.
>>>
>>> Also, this problem is *highly* asymmetric. Unnecessarily using big PK 
>>> fields wastes a little storage space - unlikely to be noticed. Migrating to 
>>> big PK fields can be a massive task (and can feel like "Django let you down 
>>> here with bad defaults") ("Ruby on Rails does it right!").
>>>
>>> It will need a careful migration guide though. Pre-existing projects may 
>>> need to migrate one table at a time to reduce downtime/load, or keep the 
>>> setting to the smaller auto field forever. I'm happy to help with this.
>>>
>>> One thing we *could* add is a deploy time system check (or a management 
>>> command, or something), to check what % of your tables' autofields' PK 
>>> values have been "used up." This allows larger projects to prioritize their 
>>> migrations.
>>>
>>> On Mon, 6 Apr 2020 at 15:37, Caio Ariede  wrote:
>>>
 Hi folks,

 I’ve been working on ticket #56 "Primary key columns should be 
 UNSIGNED"  (really old) for a while now. It’s cumbersome and hard to 
 fix for some reasons, including backwards compatibility, nothing that a 
 single PR can solve but I’ll try to summarize where things are at this 
 moment. Hopefully we can get to a consensus so I can continue.

 The problem: Django has been storing primary keys as signed integers 
 since the beginning and this is considered a waste of resources. Very few 
 people seem to use negative values as primary keys, apparently.

 The desired solution: We want to change that in a backwards-compatible 
 way to not cause 

Re: Adding ability to choose AutoField type (signed vs unsigned)

[Collin Anderson]

Having a DEFAULT_AUTOFIELD setting makes sense to me.

On Monday, April 6, 2020 at 12:48:10 PM UTC-4, Adam Johnson wrote:
>
> Jure - yes switching the setting should generate migrations for all 
> affected models. The migration guide would cover changing models' primary 
> key fields to PositiveBigAutoFields one at a time, perhaps with a mixin as 
> you've suggested. Maybe Django should provide such a mixin to ease the 
> migration.
>
> primary keys might be GUID
>>
>
> The proposal is not to move to GUID's/UUID's, as you've used in your 
> example. It's to move to bigger integers.
>
> UUID's are a bad idea for database performance, as they distribute 
> randomly across the table, preventing any cache wins. On autoincrement 
> tables, the tail end of each table is normally most frequently read and 
> written and thus cached in memory. I don't think Django should ever suggest 
> UUID's as primary keys.
>
> On Mon, 6 Apr 2020 at 16:46, Jure Erznožnik  > wrote:
>
>> Sorry if I understand stuff incorrectly, but:
>>
>> I agree with Adam where he discusses migration issues, but I also don't 
>> see how "DEFAULT_AUTOFIELD" setting could leave tables out of the 
>> migration(s). 
>>
>> My understanding is that it would cause immediate re-provisioning of all 
>> the pk fields, including in the core django modules and third-party 
>> modules. Some of them might have programmed their logic such as to include 
>> some integer math around the primary keys (and now all auto primary keys 
>> might be GUID).
>>
>> If I understand the above correctly, the setting would have to be 
>> per-module. Could it simply be done like this:
>>
>> class PKMixin(object):id = models.UUIDField(primary_key=True, )
>>
>> Naturally, then all desired models would (also) derive from this mixin. A 
>> bit of a chore, but it would not require reconfiguration of all migrations, 
>> just the ones the programmer would specify - and would only be limited to 
>> their own module.
>>
>> OTOH, JUST FOR the unsigned vs signed integer PK, it should be relatively 
>> easy to modify makemigrations code detect existing migrations for the 
>> model, detect that the only difference is IntegerField vs 
>> PositiveIntegerField and in this case skip generating the migration (for 
>> migrating the field to an unsigned one). There could also be a flag to the 
>> management command specifying to force generating said migrations.
>>
>> Of course, ignore if this is gibberish.
>>
>> LP,
>> Jure
>>
>>
>> On 06/04/2020 17:11, Adam Johnson wrote:
>>
>> I'm in favour of the move. The setting strategy seems appropriate.
>>
>> Simon's comment on the PR that this affects a small % of projects is 
>> true. But if your project does reach that scale, you're probably one of the 
>> bigger Django organizations in the world - hopefully key advocates for the 
>> framework. It's also possible to hit this on smaller projects with tables 
>> that import a lot of new rows, such as rolling time series data imports.
>>
>> Also, this problem is *highly* asymmetric. Unnecessarily using big PK 
>> fields wastes a little storage space - unlikely to be noticed. Migrating to 
>> big PK fields can be a massive task (and can feel like "Django let you down 
>> here with bad defaults") ("Ruby on Rails does it right!").
>>
>> It will need a careful migration guide though. Pre-existing projects may 
>> need to migrate one table at a time to reduce downtime/load, or keep the 
>> setting to the smaller auto field forever. I'm happy to help with this.
>>
>> One thing we *could* add is a deploy time system check (or a management 
>> command, or something), to check what % of your tables' autofields' PK 
>> values have been "used up." This allows larger projects to prioritize their 
>> migrations.
>>
>> On Mon, 6 Apr 2020 at 15:37, Caio Ariede > > wrote:
>>
>>> Hi folks,
>>>
>>> I’ve been working on ticket #56 "Primary key columns should be UNSIGNED"  
>>> (really old) for a while now. It’s cumbersome and hard to fix for some 
>>> reasons, including backwards compatibility, nothing that a single PR can 
>>> solve but I’ll try to summarize where things are at this moment. Hopefully 
>>> we can get to a consensus so I can continue.
>>>
>>> The problem: Django has been storing primary keys as signed integers 
>>> since the beginning and this is considered a waste of resources. Very few 
>>> people seem to use negative values as primary keys, apparently.
>>>
>>> The desired solution: We want to change that in a backwards-compatible 
>>> way to not cause migrations to happen in all projects using Django, in all 
>>> of a sudden. This is where things start to get difficult.
>>>
>>> These are the links for the related ticket and PR up to this point:
>>>
>>> https://code.djangoproject.com/ticket/56 (Primary key columns should be 
>>> UNSIGNED)
>>> https://github.com/django/django/pull/11900 (PR)
>>>
>>> —
>>>
>>> While I was working on PR 11900, I stumbled across this other PR 8924 
>>> "BigAutoField 

Re: Error while creating an API

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.0/faq/help/

Thanks for your understanding,

Adam

On Thu, 9 Apr 2020 at 16:50, Kushal Neupane  wrote:

> Dear all, i got error while making an API. Help me
> C:\Users\Kushal Neupane\Desktop\1. Project Folder - [SMART RESTAURANT
> POINT OF SALE] - [KUSHAL NEUPANE]\1. Project Artefact\5.
> Development\restro_app>python manage.py runserver
> Watching for file changes with StatReloader
> Performing system checks...
>
> Exception in thread django-main-thread:
> Traceback (most recent call last):
>   File "C:\Program Files (x86)\Python36-32\lib\threading.py", line 916, in
> _bootstrap_inner
> self.run()
>   File "C:\Program Files (x86)\Python36-32\lib\threading.py", line 864, in
> run
> self._target(*self._args, **self._kwargs)
>   File "C:\Program Files
> (x86)\Python36-32\lib\site-packages\django\utils\autoreload.py", line 53,
> in wrapper
> fn(*args, **kwargs)
>   File "C:\Program Files
> (x86)\Python36-32\lib\site-packages\django\core\management\commands\runserver.py",
> line 117, in inner_run
> self.check(display_num_errors=True)
>   File "C:\Program Files
> (x86)\Python36-32\lib\site-packages\django\core\management\base.py", line
> 395, in check
> include_deployment_checks=include_deployment_checks,
>   File "C:\Program Files
> (x86)\Python36-32\lib\site-packages\django\core\management\base.py", line
> 382, in _run_checks
> return checks.run_checks(**kwargs)
>   File "C:\Program Files
> (x86)\Python36-32\lib\site-packages\django\core\checks\registry.py", line
> 72, in run_checks
> new_errors = check(app_configs=app_configs)
>   File "C:\Program Files
> (x86)\Python36-32\lib\site-packages\django\core\checks\urls.py", line 13,
> in check_url_config
> return check_resolver(resolver)
>   File "C:\Program Files
> (x86)\Python36-32\lib\site-packages\django\core\checks\urls.py", line 23,
> in check_resolver
> return check_method()
>   File "C:\Program Files
> (x86)\Python36-32\lib\site-packages\django\urls\resolvers.py", line 406, in
> check
> for pattern in self.url_patterns:
>   File "C:\Program Files
> (x86)\Python36-32\lib\site-packages\django\utils\functional.py", line 48,
> in __get__
> res = instance.__dict__[self.name] = self.func(instance)
>   File "C:\Program Files
> (x86)\Python36-32\lib\site-packages\django\urls\resolvers.py", line 587, in
> url_patterns
> patterns = getattr(self.urlconf_module, "urlpatterns",
> self.urlconf_module)
>   File "C:\Program Files
> (x86)\Python36-32\lib\site-packages\django\utils\functional.py", line 48,
> in __get__
> res = instance.__dict__[self.name] = self.func(instance)
>   File "C:\Program Files
> (x86)\Python36-32\lib\site-packages\django\urls\resolvers.py", line 580, in
> urlconf_module
> return import_module(self.urlconf_name)
>   File "C:\Program Files (x86)\Python36-32\lib\importlib\__init__.py",
> line 126, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 994, in _gcd_import
>   File "", line 971, in _find_and_load
>   File "", line 955, in
> _find_and_load_unlocked
>   File "", line 665, in _load_unlocked
>   File "", line 678, in exec_module
>   File "", line 219, in
> _call_with_frames_removed
>   File "C:\Users\Kushal Neupane\Desktop\1. Project Folder - [SMART
> RESTAURANT POINT OF SALE] - [KUSHAL NEUPANE]\1. Project Artefact\5.
> Development\restro_app\restro_app\urls.py", line 26, i
> n 
> path('api/', include('tableOrder.urls')),
>   File "C:\Program Files
> (x86)\Python36-32\lib\site-packages\django\urls\conf.py", line 34, in
> include
> urlconf_module = import_module(urlconf_module)
>   File "C:\Program Files (x86)\Python36-32\lib\importlib\__init__.py",
> line 126, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 994, in _gcd_import
>   File "", line 971, in _find_and_load
>   File "", line 941, in
> _find_and_load_unlocked
>   File "", line 219, in
> _call_with_frames_removed
>   File "", line 994, in _gcd_import
>   File "", line 971, in _find_and_load
>   File "", line 953, in
> _find_and_load_unlocked
> ModuleNotFoundError: No module named 'tableOrder'
>
> Traceback (most recent call last):
>   File "manage.py", line 21, in 
> main()
>   File "manage.py", line 17, in main
> execute_from_command_line(sys.argv)
>   File "C:\Program Files
> (x86)\Python36-32\lib\site-packages\django\core\management\__init__.py",
> line 401, in execute_from_command_line
> utility.execute()
>   File "C:\Program Files
> 

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

[Adam Johnson]

I for one am quite surprised to learn the admin has this behaviour.

I'm extra surprised it assumes it's in English if only ASCII letters are
used. This is quite a naïve assumption  (See what I did in that sentence?)

Was removal of these words introduced for SEO reasons?
>

Seems likely.

Personally, for the reasons you've presented I think it would make sense to
remove this behaviour. We can probably document how to wrap window.URLify
to preserve the old behaviour.

On Wed, 8 Apr 2020 at 20:38, Andy Chosak  wrote:

> Automatic slug generation in ModelAdmin via prepopulated_fields
> 
> uses a urlify.js
> 
> file which, among other behaviors, removes certain stop words
> 
> from the slug. For example, a string like "To be or not to be, that is the
> question" will generate a slug "be-or-not-be-question", not
> "to-be-or-not-to-be-that-is-the-question" as one might expect. I’d like to
> solicit feedback on the idea of removing this logic so that slugs can
> contain these words.
>
> For reference, the current list is: a, an, as, at, before, but, by, for,
> from, is, in, into, like, of, off, on, onto, per, since, than, the, this,
> that, to, up, via, with.
>
> Django ticket #30538 
> mentions this behavior as part of a more general comparison between
> urlify.js and Python slugify
> .
> It was closed as wontfix due to reasons of backwards compatibility. Per the 
> triaging
> guidelines
> ,
> I’m making this post to solicit feedback on the more specific question of
> addressing stopword removal in the JS code only -- not to try to address
> any other differences in behavior between these two methods. There’s been
> quite a bit of discussion on generating slugs for non-English languages
> (for example #2282 ), and
> this post is not intended to reopen that discussion.
>
> The current list of stopwords being removed seems to have been the same since
> at least 2005
> 
> (the earliest code I can find including this logic). Some of these words
> feel a little unexpected, for example “before” and “since”. After 15 years
> it seems reasonable to revisit the list and consider whether it still makes
> sense.
>
> Was removal of these words introduced for SEO reasons? If so, is this
> still a recommended default behavior? In 2020, search engines like Google
> seem smart enough to interpret them properly. Here's
>  an arbitrary page that
> discusses this and includes a much longer list of what might be considered
> stopwords. As another datapoint, the popular WordPress Yoast SEO plugin
> used to remove stopwords, but stopped doing so
>  a few years back.
>
> Potentially outdated SEO concerns aside, does this behavior still align
> well with the needs and desires of Django users? Is this something this
> community would be open to revisiting? Thanks for your consideration.
>
> (One minor point on language support: allowing these words would help to
> resolve at least some of the unequal treatment given to English over other
> languages, for example #12905
> . See also wagtail#4899
> , from which much of this
> post has been copied, for an example of how this logic impacts a
> Django-based CMS.)
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/fb6c9596-951d-4102-91b5-b5fd9c8c6340%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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 view this discussion on the web visit 

Re: Error while creating an API

[Abhijeet Viswa]

Hey,

This mailing list is meant the development of Django itself and not for 
problems faced by users when developing a Django app. 
dja...@googlegroups.com is in fact related to that latter.


Also checkout the "Getting Help" page: 
https://docs.djangoproject.com/en/3.0/faq/help/ 



Regards and all the best,
Abhijeet

PS: All that being said, I think your problem is because the tableOrder 
module/app doesn't exist.



On 09/04/20 9:20 pm, Kushal Neupane wrote:

Dear all, i got error while making an API. Help me
C:\Users\Kushal Neupane\Desktop\1. Project Folder - [SMART RESTAURANT 
POINT OF SALE] - [KUSHAL NEUPANE]\1. Project Artefact\5. 
Development\restro_app>python manage.py runserver

Watching for file changes with StatReloader
Performing system checks...

Exception in thread django-main-thread:
Traceback (most recent call last):
  File "C:\Program Files (x86)\Python36-32\lib\threading.py", line 
916, in _bootstrap_inner

    self.run()
  File "C:\Program Files (x86)\Python36-32\lib\threading.py", line 
864, in run

    self._target(*self._args, **self._kwargs)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\utils\autoreload.py", line 
53, in wrapper

    fn(*args, **kwargs)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\commands\runserver.py", 
line 117, in inner_run

    self.check(display_num_errors=True)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\base.py", 
line 395, in check

    include_deployment_checks=include_deployment_checks,
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\base.py", 
line 382, in _run_checks

    return checks.run_checks(**kwargs)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\checks\registry.py", 
line 72, in run_checks

    new_errors = check(app_configs=app_configs)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\checks\urls.py", line 
13, in check_url_config

    return check_resolver(resolver)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\checks\urls.py", line 
23, in check_resolver

    return check_method()
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\urls\resolvers.py", line 
406, in check

    for pattern in self.url_patterns:
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\utils\functional.py", line 
48, in __get__

    res = instance.__dict__[self.name] = self.func(instance)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\urls\resolvers.py", line 
587, in url_patterns
    patterns = getattr(self.urlconf_module, "urlpatterns", 
self.urlconf_module)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\utils\functional.py", line 
48, in __get__

    res = instance.__dict__[self.name] = self.func(instance)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\urls\resolvers.py", line 
580, in urlconf_module

    return import_module(self.urlconf_name)
  File "C:\Program Files (x86)\Python36-32\lib\importlib\__init__.py", 
line 126, in import_module

    return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 994, in _gcd_import
  File "", line 971, in _find_and_load
  File "", line 955, in 
_find_and_load_unlocked

  File "", line 665, in _load_unlocked
  File "", line 678, in exec_module
  File "", line 219, in 
_call_with_frames_removed
  File "C:\Users\Kushal Neupane\Desktop\1. Project Folder - [SMART 
RESTAURANT POINT OF SALE] - [KUSHAL NEUPANE]\1. Project Artefact\5. 
Development\restro_app\restro_app\urls.py", line 26, i

n 
    path('api/', include('tableOrder.urls')),
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\urls\conf.py", line 34, in 
include

    urlconf_module = import_module(urlconf_module)
  File "C:\Program Files (x86)\Python36-32\lib\importlib\__init__.py", 
line 126, in import_module

    return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 994, in _gcd_import
  File "", line 971, in _find_and_load
  File "", line 941, in 
_find_and_load_unlocked
  File "", line 219, in 
_call_with_frames_removed

  File "", line 994, in _gcd_import
  File "", line 971, in _find_and_load
  File "", line 953, in 
_find_and_load_unlocked

ModuleNotFoundError: No module named 'tableOrder'

Traceback (most recent call last):
  File "manage.py", line 21, in 
    main()
  File "manage.py", line 17, in main
    execute_from_command_line(sys.argv)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\__init__.py", 
line 401, in execute_from_command_line

    utility.execute()
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\__init__.py", 
line 395, in execute

    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "C:\Program Files 

Error while creating an API

[Kushal Neupane]

Dear all, i got error while making an API. Help me
C:\Users\Kushal Neupane\Desktop\1. Project Folder - [SMART RESTAURANT POINT 
OF SALE] - [KUSHAL NEUPANE]\1. Project Artefact\5. 
Development\restro_app>python manage.py runserver
Watching for file changes with StatReloader
Performing system checks...

Exception in thread django-main-thread:
Traceback (most recent call last):
  File "C:\Program Files (x86)\Python36-32\lib\threading.py", line 916, in 
_bootstrap_inner
self.run()
  File "C:\Program Files (x86)\Python36-32\lib\threading.py", line 864, in 
run
self._target(*self._args, **self._kwargs)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\utils\autoreload.py", line 53, 
in wrapper
fn(*args, **kwargs)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\commands\runserver.py",
 
line 117, in inner_run
self.check(display_num_errors=True)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\base.py", line 
395, in check
include_deployment_checks=include_deployment_checks,
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\base.py", line 
382, in _run_checks
return checks.run_checks(**kwargs)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\checks\registry.py", line 
72, in run_checks
new_errors = check(app_configs=app_configs)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\checks\urls.py", line 13, 
in check_url_config
return check_resolver(resolver)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\checks\urls.py", line 23, 
in check_resolver
return check_method()
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\urls\resolvers.py", line 406, in 
check
for pattern in self.url_patterns:
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\utils\functional.py", line 48, 
in __get__
res = instance.__dict__[self.name] = self.func(instance)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\urls\resolvers.py", line 587, in 
url_patterns
patterns = getattr(self.urlconf_module, "urlpatterns", 
self.urlconf_module)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\utils\functional.py", line 48, 
in __get__
res = instance.__dict__[self.name] = self.func(instance)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\urls\resolvers.py", line 580, in 
urlconf_module
return import_module(self.urlconf_name)
  File "C:\Program Files (x86)\Python36-32\lib\importlib\__init__.py", line 
126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 994, in _gcd_import
  File "", line 971, in _find_and_load
  File "", line 955, in _find_and_load_unlocked
  File "", line 665, in _load_unlocked
  File "", line 678, in exec_module
  File "", line 219, in 
_call_with_frames_removed
  File "C:\Users\Kushal Neupane\Desktop\1. Project Folder - [SMART 
RESTAURANT POINT OF SALE] - [KUSHAL NEUPANE]\1. Project Artefact\5. 
Development\restro_app\restro_app\urls.py", line 26, i
n 
path('api/', include('tableOrder.urls')),
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\urls\conf.py", line 34, in 
include
urlconf_module = import_module(urlconf_module)
  File "C:\Program Files (x86)\Python36-32\lib\importlib\__init__.py", line 
126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 994, in _gcd_import
  File "", line 971, in _find_and_load
  File "", line 941, in _find_and_load_unlocked
  File "", line 219, in 
_call_with_frames_removed
  File "", line 994, in _gcd_import
  File "", line 971, in _find_and_load
  File "", line 953, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'tableOrder'

Traceback (most recent call last):
  File "manage.py", line 21, in 
main()
  File "manage.py", line 17, in main
execute_from_command_line(sys.argv)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\__init__.py", 
line 401, in execute_from_command_line
utility.execute()
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\__init__.py", 
line 395, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\base.py", line 
328, in run_from_argv
self.execute(*args, **cmd_options)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\commands\runserver.py",
 
line 60, in execute
super().execute(*args, **options)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\base.py", line 
369, in execute
output = self.handle(*args, **options)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\commands\runserver.py",