Re: Proposal - Warn user when creating or applying a delete migration?

2020-06-12 Thread Denis Urman
It's easy enough to read the output before you migrate. It's pretty darn 
hard to accidentally delete an entire Model. It'd have to be a new or 
obscure Model with no references in your Views, no ForeignKeys to it, etc 
etc. Deleting a Field accidentally on the other hand is pretty easy to do. 
I do feel that migrations are a major sore point in Django. I don't believe 
that *"*Make sure to read the output to see what makemigrations* thinks you 
have changed - it’s not perfect, and for complex changes it might not be 
detecting what you expect." * is good enough for us. A flag/option for this 
wouldn't hurt.

-- 
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/6262515b-ca57-4708-8240-fb618115cc54o%40googlegroups.com.


Re: command for stopping server

2020-09-07 Thread Denis Urman
The canonical way to run a Django server is to link it up to a WSGI (uWSGI)
or gunicorn, then run Apache or Nginx on top of that. These latter two
things are typically handled through systemd. Some people use Docker or
Supervisor, but that might be a lot for you to learn right now. Gunicorn &
Nginx is plenty.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Sep 7, 2020 at 12:25 PM Adam Johnson  wrote:

> Antonin,
>
> Uri is right that runserver is only suitable for development. It's also
> worth looking at during development - log output includes system check
> failures, new migration detection, and stack traces when bugs occur. I
> normally have it in a terminal window.
>
> If you definitely want to run it in the background during development,
> it's not a trivial problem, so I don't think Django should build anything.
> Plenty of mature options already exist:
>
>- Honcho: https://honcho.readthedocs.io/en/latest/
>- Supervisor: http://supervisord.org/
>- docker-compose, if you run django inside docker
>- Linux's systemd
>- macOS' launchd
>- etc.
>
> Hope those help.
>
> ‪On Mon, 7 Sep 2020 at 15:47, ‫אורי‬‎  wrote:‬
>
>> I think the server run by "python manage.py runserver" is just a
>> debugging server, it is not suitable for production. For production you run
>> a web server such as Nginx or Apache which you configure to execute Django.
>> אורי
>> u...@speedy.net
>>
>>
>> On Mon, Sep 7, 2020 at 4:37 PM Antonín Drdácký 
>> wrote:
>>
>>> Hello there,
>>>
>>> This question on StackOverflow is a workaround for stopping the server
>>>
>>> https://stackoverflow.com/questions/27066366/django-development-server-how-to-stop-it-when-it-run-in-background
>>>
>>> Basically I would like to run the server and stop it by a program, it is
>>> hard, when the default way is literally "pressing ctrl+C",
>>> killing the process is different on different OS'es.
>>> When searching the web (StackOverflow) users replies to individual
>>> answers were "This worked for me." or "This didn't work for me.",
>>> this showcases that different conditions make it hard to get to actually
>>> stopping the server.
>>>
>>> A unified solution would be very nice. If we want to keep "python
>>> manage.py runserver" together with "press ctrl+C to quit",
>>> then I would suggest a new command, let's call it "startserver", that
>>> would be non-blocking, running subprocess, or something,
>>> once the user is done he simply calls "stopserver" to stop it.
>>> "startserver" vs "runserver" might be similar for some, suggest
>>> different command name if you like.
>>>
>>> It is only my suggestion, I don't care if it will be more complicated as
>>> long as it will "just work" on all OS'es and will be clear to use.
>>>
>>> Thanks for your time and consideration
>>> Antonín Drdácký
>>>
>>> --
>>> 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/CALALaaN-e-qQ%3DBLuGb4QVAx%2BpEDxWaiRAWFoPnDGoPkNv_Of-w%40mail.gmail.com
>>> 
>>> .
>>>
>> --
>> 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/CABD5YeE2howmrCruPmbALRV7UKACCjrSCJ0_%3D9rRmpFXhpKVYQ%40mail.gmail.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
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2zcWrE99PYrgvX5%3D%3DSQvBaWP6zS3fLJQ0LbY6hpPqcRg%40mail.gmail.com
> 
> .
>



Re: Model Generation for CSV, XLS Files

2020-11-28 Thread Denis Urman
The CSV module in the Python standard library has solved the issues
mentioned in this thread vis a vis format. No need to reinvent the wheel.
There are options and flags for field names and delimiters. Before relying
on a third party depencency, one must demonstrate the necessity. What edge
cases does CSV not account for and why is it our responsibility to solve
for them?

Serializing/deserializing from a CSV to a Model is trivial if the Models
are already written. We need to figure out how to handle arrays/sets for
normalized databases with foreign keys. For example in one of my projects,
an Invoice has a Vendor (many to one) Perhaps a flag for which attributes
to fetch for the reverse set and which set (list, dictionary, etc.) to
return them as?

I'd love to jump on this and come up with a RFC or something. I have a huge
amount of business logic related to (de)serialization in my app.

On Sat, Nov 28, 2020, 10:05 AM Muskan Vaswan  wrote:

> Alright Mariusz, (sorry for messing up your name) then I think that puts
> an end to this particular conversation, I appreciate your feedback and
> help, same goes for everyone. I'll try to make myself useful in some other
> way then!
>
> On Saturday, 28 November 2020 at 14:12:29 UTC+5:30 Mariusz Felisiak wrote:
>
>> Russ pointed out the need for a standardized format in csv files, and in
>>> turn Adam suggested that the first line begin the table name. I have a
>>> slightly different suggestion. It is a well known convention to put the
>>> column names as comma separated values in the first line of the csv file. I
>>> suggest we leave it at that.
>>>
>>> *-1*
>> I wouldn't call in a convention. I've imported thousands of CSV files in
>> dozens of different formats in my life. The lack of a standard is still a
>> strong argument against including it in Django. It's not something that we
>> want to maintain in Django. It sounds like a third-party package with a
>> custom serializer is the best way to proceed.
>>
>> Best,
>> Mariusz
>> *not Markzus ;)*
>>
> --
> 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/151f28cc-dd85-47f1-ad28-5f99aeea7539n%40googlegroups.com
> 
> .
>

-- 
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/CAK1R69rjc%2BG8pp3smP6EUbqEu-_AJXrKm2_ZMsO3if3KDLzTcA%40mail.gmail.com.


Re: improvement for the front end

2022-03-16 Thread Denis Urman
Dude I saw this post on Reddit today! When I checked GitHub I saw I was already 
following you and I was like wait what? And I remembered our conversation.

Great job 👏 I read through the docs earlier. Very impressive. I dont work with 
Python at the moment so I can’t use it but I’m going to follow this project.

Sent from my iPhone

> On Mar 16, 2022, at 7:11 PM, Silvio  wrote:
> 
> Check out my recently launched project as well: https://www.reactivated.io
> 
> Zero-configuration Django and React. Basically, you use React as a template 
> engine for Django.
> 
>> On Wednesday, March 16, 2022 at 12:25:31 PM UTC-4 Adam Johnson wrote:
>> Hi
>> 
>> I think you might enjoy reading up on htmx: https://htmx.org/ . This allows 
>> you to write html attributes that fetch extra HTML fragments from Django, no 
>> JavaScrip required. It's been quite popular at Django conferences recently. 
>> I maintain the small package django-htmx which has some tools and tips for 
>> using htmx with Django: https://django-htmx.readthedocs.io/en/latest/ .
>> 
>> Thanks,
>> 
>> Adam
>> 
>>> On Wed, Mar 16, 2022 at 2:08 PM Jans Green  wrote:
>>> good day Djangueros!, this is a message for the most advanced in the 
>>> language, it is very tedious to work with django when you need your web to 
>>> be dynamic in the front end, having a lot of dependency on javascript, 
>>> that's why you use djano restframework to divide django as back end and 
>>> front end use react js or other, do you know that there is render? render 
>>> reads any .HTML file and displays it as such, because based on this we 
>>> create something that reads any js file, and inside the file looks for any 
>>> command that starts with (% some code %) and through this the django 
>>> backend and the javascripts frontend communicates directly without going 
>>> through the HTML, that is Django =><=Javascripts =>HTML would be something 
>>> like this variable = 12345 Render(variable, "javascripts.js"), the reason 
>>> for this is that I see a lot of consumption of resources using django as 
>>> absolutely backend and for front end other methods like reactjs, django has 
>>> a server and for the front end it needs another one and they communicate by 
>>> api rest. what do they say cheer up?
>>> 
>>> 
>>> Español==
>>> 
>>> buen dia Djangueros!, este es un mensaje para los mas avanzados en el 
>>> lenguaje, es bien tedioso trabajar con django cuando necesita de que tu web 
>>> sea dinamica en el front end, teniendo mucha dependencia de javascript, por 
>>> ello usas djano restframework para dividir django como back end y front end 
>>> usan react js u other, ustedes saben que existe render? render lee 
>>> cualquier archivo .HTML y la mostra como tal, porque basado en esto creamos 
>>> algo que lea cualquier archivo js, ​​y dentro del archivo busque cualquier 
>>> comando que empieze con (% algun codigo %) y atravez de este el backend de 
>>> django y el frontend de javascripts se comunica directamente sin pasar por 
>>> el HTML, osea Django =><=Javascripts =>HTML seria algo asi variable = 12345 
>>> Render(variable, "javascripts.js"), la razon de esto es que veo mucho 
>>> consumo de recursos usando django como absolutamente backend y para front 
>>> end otro metodos como reactjs, django posee un servidor y para el front end 
>>> necesita otro y se comunican por api rest. que dicen se animan?
>> 
>>> -- 
>>> 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-develop...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/bd18a9db-eb41-48a6-99db-470c9022e8d8n%40googlegroups.com.
> 
> -- 
> 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/5e1b1b03-253a-4543-bcef-0b406ae6686en%40googlegroups.com.

-- 
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/C315803C-AA82-4BF9-9314-DDB5143DE52F%40gmail.com.