|
Thermopyle posted:The goal of DDD is largely about helping you understand your own codebase when the business logic gets too complicated. Sure, if I was designing from scratch, I'd probably do all api requests and caching from a services module, but if you're not having a hard time with the complexity I think I'd leave them where they are but use django's @cached_property decorator and not worry about caching the values on the object instance myself. Good point. Didn't know about the @cached_property! Will convert my @property decorators over to that. I think a lot of the complexity I'm facing comes down to a poorly designed data model from the business, so I'll need to go back and rethink some of this to see if I can paper over any of it.
|
# ? Apr 18, 2018 19:45 |
|
|
# ? Jun 3, 2024 20:57 |
|
Fluue posted:Good point. Didn't know about the @cached_property! Will convert my @property decorators over to that. The way cached_property works is pretty neat. On first access it retrieves or calculates the value you're looking for and then it replaces itself on the instance. One benefit to this is that it's faster to access then the typical practice of storing the calculated value in another instance attribute like self._im_the_real_value. Either way you do it, you have to remember that its cached. Typically, a model instance is pretty short lived...you retrieve it and get an attribute or two off of it. However, if you do something like instance.refresh_from_db(), and your cached property uses values from the db in its calculation, your property is now wrong and out-of-date.
|
# ? Apr 19, 2018 20:53 |
|
Sorry to bother you with what is probably a simple problem but my search skills (or comprehension of the Django docs) have failed me. I keep getting this error: code:
Main urls.py: code:
code:
code:
code:
if I use hard-coded URLs in the template it works fine and will display that location and its storageareas: code:
e: fixed url example above e2: Jeez, I don't understand this at all. If I create a slightly different URL pattern, removing the namespacing and app_name like so: code:
code:
F4rt5 fucked around with this message at 10:45 on Apr 28, 2018 |
# ? Apr 28, 2018 07:02 |
|
Dominoes posted:Hey dudes. Looking for wisdom on what URL to query for Django Rest tied to a Create-React-App setup. I'm assuming you are familiar with CRA's ability to proxy requests for you so you can just use "real" URLs in development? https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#proxying-api-requests-in-development
|
# ? Apr 28, 2018 15:57 |
|
JazzmasterCurious posted:URL pattern issues It's because of how you defined your url pattern I think. The error is specific: "Reverse for 'location-detail' with no arguments not found." Your url pattern: code:
code:
Hope that helps!
|
# ? Apr 28, 2018 17:00 |
|
^^^ Thanks for the kind help; it worked perfectly. I didn't know about being able to send parameters in a {% %} tag, it makes much more sense now. Thanks again!
|
# ? Apr 30, 2018 06:13 |
|
So let us say I have an app and it's running in three environments (dev, staging, production). I on occasion need to add a model instance via the admin so a picker in the app has a new entry. Currently, I am doing this the stupid way by going to each environment and manually adding. How do smart people do this? All my is returning page after page of how to get different settings across environments because apparently I can't think of a way to phrase my search without that happening...
|
# ? May 4, 2018 14:44 |
|
Without knowing more about the context, I'd think about writing a data migration ( https://docs.djangoproject.com/en/2.0/topics/migrations/#data-migrations ) to add the necessary instances on deploy, since it sounds like the data is relatively static across all your environments.
|
# ? May 4, 2018 15:13 |
|
Eleeleth posted:Without knowing more about the context, I'd think about writing a data migration ( https://docs.djangoproject.com/en/2.0/topics/migrations/#data-migrations ) to add the necessary instances on deploy, since it sounds like the data is relatively static across all your environments. That looks pretty spot on. Thanks! And yeah, the cases where I'm doing this are for mostly-static things like options in a dropdown and so on that don't change between environments.
|
# ? May 4, 2018 15:38 |
Is it possible to package up an entire django project? In the docs I saw this page about packaging an app: https://docs.djangoproject.com/en/2.0/intro/reusable-apps/#packaging-your-app In that case it seems like it's just packaging up "polls" - I want to package up all of "mysite" though, settings, templates, etc I was thinking this would simplify deployment a bit, turning it into just a "pip install my_site" followed by a collectstatic & migrate
|
|
# ? May 9, 2018 02:38 |
|
fletcher posted:Is it possible to package up an entire django project? git?
|
# ? May 9, 2018 02:48 |
Lumpy posted:git? Yeah that's what I'm currently doing, would prefer to pull a build artifact from internal pypi server rather than source control though.
|
|
# ? May 9, 2018 08:08 |
|
fletcher posted:Yeah that's what I'm currently doing, would prefer to pull a build artifact from internal pypi server rather than source control though. ah, gotcha.
|
# ? May 9, 2018 15:10 |
I'm thinking that given how little information I am finding out there about how to do this, it may be a sign. I am surprised nobody else is doing this though...
|
|
# ? May 10, 2018 01:09 |
|
I'm just not sure what you're hoping to gain over other methods of getting your code on the server.
|
# ? May 10, 2018 01:16 |
|
Yeah, I mean:code:
|
# ? May 10, 2018 02:24 |
|
Python code:
What am I doing wrong here? I don't really want to make the parent field nullable. It's like just the act of reading self.parent, even to check if it's None, is enough to trigger the error. This is in Django 1.11, here's where the error is raised: https://github.com/django/django/blob/2b882a4bd954c8a6b1447f8fc0841a3352514c26/django/db/models/fields/related_descriptors.py#L193, so if I'm reading this right, just by reading self.parent, I'm ending up in that __get__. So how can I give it a value if it's None, if I can't check that it's None? Edit: Oops... of course, I should be reading self.parent_id instead of self.parent. Duh. epswing fucked around with this message at 13:40 on May 10, 2018 |
# ? May 10, 2018 05:11 |
Lumpy posted:Yeah, I mean: Yeah, agreed it's definitely not tedious the existing way I'm doing it. I guess part of the problem is that deployments are usually done during off hours, and occasionally this means that our git server is also undergoing maintenance at the same time we want to do a deploy to production. It'd be nice to eliminate that dependency, with an s3 backed pypi repo I wouldn't have to worry about it. I can achieve the same goal just my creating an archive and uploading it somewhere, it just seemed like something that setup.py would have been able to handle for me. fletcher fucked around with this message at 06:24 on May 10, 2018 |
|
# ? May 10, 2018 06:17 |
|
There's things like fabric (but I don't know if that's python3 compatible yet?) But the reality is when you want to start doing things "properly" you have to start looking at things like docker
|
# ? May 10, 2018 11:56 |
|
fletcher posted:Yeah, agreed it's definitely not tedious the existing way I'm doing it. I suggest this route because this way you don't have to gently caress with dependencies at deploy. Or docker
|
# ? May 10, 2018 12:57 |
|
WTF, why is your git server down for maintenance so much that you would even be looking into doing this.
|
# ? May 10, 2018 15:05 |
|
Is there a less ugly way to do this? Specifically the bit about correct_answer_id = -1.code:
|
# ? May 23, 2018 18:54 |
|
huhu posted:Is there a less ugly way to do this? Specifically the bit about correct_answer_id = -1. I think you need to post your data model and intentions. For one you could just set a default value on the Question model. Aside that though, you have a 1->many or 1->1 relationship but then save the reverse to the other model when you could just use the existing answer FK to the question instead. From a glance you might have a requirements modelling mismatch.
|
# ? May 23, 2018 19:05 |
|
I want each question to have only one correct answer and I don't want a boolean on each answer so I thought I'd add an ID that points to the correct answer. code:
|
# ? May 24, 2018 16:25 |
E: probably missing something obvious here
|
|
# ? May 24, 2018 16:39 |
|
huhu posted:I want each question to have only one correct answer and I don't want a boolean on each answer so I thought I'd add an ID that points to the correct answer. When you want to relate to a model instance, you use a FK, not an IntegerField.
|
# ? May 24, 2018 17:41 |
|
huhu posted:I want each question to have only one correct answer and I don't want a boolean on each answer so I thought I'd add an ID that points to the correct answer. I think the problem is arising in that you have both models pointing at each other in some way, so you end up with your convoluted creation with a placeholder index since both expect the other to exist first. I'm not sure why you don't want a boolean on the Answer model, but that's going to be the correct (read: simplest) solution, at least if we're constrained to leave your model relationships how they are. I would change it to: code:
code:
Better yet, combine the two for what I think is the most logical solution code:
|
# ? May 24, 2018 18:58 |
|
Has anyone done anything with geodjango? I've never used it. I'm thinking about a potential project right now and for some models I might store the users location when they create an object. Easy enough with a couple of DecimalFields. I can imagine future iterations of this project wanting to do more like calculate distances...maybe some sort of geo-fencing, etc. Should I just start out geodjango, or just migrate to it when I need more capabilities?
|
# ? May 24, 2018 20:39 |
Thermopyle posted:Should I just start out geodjango, or just migrate to it when I need more capabilities? I'm in kind of the same boat right now, but with a Java project that we started out with storing GeoJSON in a char field. Now we are migrating it to PostGIS for those additional capabilities, I wish we had just started out with PostGIS to begin with, would have eliminated some of this extra overhead of doing the migration. It's not a huge issue, but I'd say maybe just start out with geodjango if you know that's where it is headed anyways. I had never heard of geodjango before, looks pretty neat.
|
|
# ? May 24, 2018 21:25 |
Super psyched for one of my projects actually, the GIS stuff felt half-baked last time I worked with it (a year or two ago).
|
|
# ? May 24, 2018 22:33 |
|
I've got a situation where I want to define a relationship in a superclass. Say I've got abstract classes Python code:
Python code:
I've tried something like this, which sets the school_class in the subclass: Python code:
Any thoughts/ideas?
|
# ? Jun 6, 2018 23:19 |
|
Class variables are class variables, not instance variables so it's not surprising that self didnt work...the variable called self by convention only exists inside methods as the first parameter. You could call it 'instance' or 'foo' or whatever, the name is just a convention, but python passes the instance as the first argument to all methods when you call them. DRF's queryset and serializer class variables are different because they are never referred to at the level of the class, only inside methods and at that point all class variables have been initialized. Django model fields are defined at the class level, so you'll never be able to reference something in a ancestor class from within a parent class. It just doesn't exist at that point.
|
# ? Jun 7, 2018 00:16 |
|
Here's a neat thing I've been doing. Using the inspect and ast modules along with django's checks framework to enforce some style and code stuff. Stolen from this guy. Here's stuff he's enforcing: quote:H001: Field has no verbose name. We have some abstract model classes that require some configuration by the model that is implementing them. I'm writing some checks to make sure thats done correctly right now.
|
# ? Jun 7, 2018 22:29 |
|
Thermopyle posted:Here's a neat thing I've been doing. Could you explain this like I am 5? What problem does this solve?
|
# ? Jun 7, 2018 23:00 |
|
The same problems it solves when Django itself uses them. Look at Django's list of checks. I'm not sure if I can describe it more simply than the guy does in the blog post I linked. Their business requires all fields verbose_text to be translated via gettext. They wrote a check to make sure that is done.
|
# ? Jun 7, 2018 23:16 |
|
I've got a form on the frontend where I can insert text, an author, and a category. The POST data for such a creation would look like this, if the author and category already exist in the backend:code:
|
# ? Jun 9, 2018 03:13 |
|
huhu posted:Is there a straightforward way to handle this? All the thoughts I have seem to have bad code smell (checking whether author is an int indicating an id or a string indicating a new entry, adding extra fields to the post, doing one request to create the author and another request to submit the rest of the data) I would have it pass the strings, regardless of if it's new or existing. Then your view method can try to look up the records by name and create them if necessary. Make sure to use a unique constraint on the author and category name fields.
|
# ? Jun 9, 2018 21:00 |
|
I've noticed when dumping SQL queries to a log file that all my queries appear to be duplicated. For example, in a single request: quote:[2018-06-11 16:42:16] DEBUG utils (0.001) SELECT "django_session"."session_key", "django_session"."... Any idea what could be causing this? I'm using Django 1.11, and Python 2.7, with the dev server talking to SQLite. I'm sure I'm not actually making all these queries twice each.
|
# ? Jun 11, 2018 21:45 |
|
When I see that it's always a logging config issue. Like logging in a root logger and in one of the Django-specific loggers.
|
# ? Jun 11, 2018 21:52 |
|
|
# ? Jun 3, 2024 20:57 |
|
Thermopyle posted:When I see that it's always a logging config issue. Right, I wondered if it was maybe just a logging issue. Is it because I've got both 'django' and 'django.db.backends'? Should one of them not propagate? My 'loggers' looks like this code:
|
# ? Jun 11, 2018 22:00 |