Re: domains vs sub-domains
On Mon, Nov 9, 2009 at 9:38 PM, Chriswrote: > > I've recently been in discussion about which is better to have. > > http://media.example.com OR > http://example.com/media/ > > 1) The first method, I've been told, allows you to make more requests. > IE for example can only make like 4 requests at a given time on a > given domain. but, if you use sub-domains, you can make additional > requests (4 additional in the example of IE). > > 2) The second method is a more canonical approach and to me is the > preferred approach. The person arguing this point says that the > additional requests cannot be made on sub-domains b/c browsers issue X > amount of requests on a per domain basis therefore sub-domains do > create additional requests. Browsers have a limit on simultaneous requests per host name, not per domain name. > > I've also been told that these arguments are really not that big of a > deal. Like nearly everything in computing, there is no absolute answer to this that is correct under all circumstances. But my experience is that downloading more media resources simultaneously will generally improve the user-perceived response time of the initial access to a media-rich page. And, given how important first impressions are, that is very much worth considering. After the first load of a given page, there will be less impact as long as the resources remain cached locally by the browser. > > Which method should I adopt? I personally like the second method, but > if it will effect performance/ loading times at all then I should go > with the first method. I will be serving things like media and API's > on a separate server or instance. Any thoughts? There are a couple additional of reasons to consider option (1). First, since you are serving static resources only, you don't need to serve them with Django -- you can pick a highly optimized web server like nginix or Apache for serving the media resources. Second, they don't have to be served by the same physical server, which can definitely improve your application's scalability. You can play configuration games and accomplish some of both of these benefits with option (2), but it's a *lot* more configuration work. As a final thought, it's instructive to note that the Ruby on Rails equivalent to media-serving template tags have built in support for spreading the media requests, even for a single page, across as many media asset hosts as you wish to configure, with no impact on the templates themselves. And, in a globally accessed application, you can even use asset host names on a content delivery network so that media resources get served from a geographically close server, which will (again) improve the user-perceived responsiveness of your application. Sounds like a few other people in the world have found approach (1) to be worth the effort. Craig PS: WIth regards to aesthetics, does the *user* of your application care what the media URLs look like? Nope, I didn't think so either. So, neither should *you* make that a primary decision criteria :-). > > Thanks in advance for input. > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: How to define a "has-a" relationship in dJango models
On Wed, Sep 16, 2009 at 3:15 PM, Javier Guerra <jav...@guerrag.com> wrote: > > On Wed, Sep 16, 2009 at 1:01 PM, PlanetUnknown > <nikhil.kodil...@gmail.com> wrote: >> >> Thanks Karen. >> Let me explain it a bit more. >> e.g. >> All CONTACT details are present in one table - email, home address, >> work address, home phone, work phone etc. >> Forget about the statement about growing for now. >> Since each user "has-a" contact it is a pure one-to-one relationship >> and not a one-to-many or many-to-one; each user in the USER table will >> have only one corresponding entry in the CONTACT table. >> Does this help explaining the issue ? >> The above is just an example, the main question is how does one >> usually implement a "has-a" relationship in dJango. > > > i think a big part of your problem is that you're using java-inspired > OOP terminology. it's much easier if you use RDBMS terminology (after > all, it will all be stored in a RDBMS). I guess that the Oracle/Java > systems you're used to show the DB as a persistence system for > objects, while Django's ORM creates classes that represent the DB. > same thing, different philosophies. I'm not much into "my XXX is bigger/stronger/better than your XXX" games, but it is worth noting that Java based ORM frameworks (including JPA and Hibernate) definitely understand what a one-to-one versus a many-to-one relationship means :-). Craig McClanahan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: How to define a "has-a" relationship in dJango models
On Wed, Sep 16, 2009 at 7:15 AM, PlanetUnknownwrote: > > For example - User HAS "Contacts"; User HAS "Preferences" > Usually (I'm from an Oracle/Java background) the Contacts table would > have a "user-id" foreign key. > However Django models refer Foreign Key relations as "Many-to-one", > but that is not true in my case. > There is only one Contact table for a User and it might keep growing > as new fields are added. > Don't want to clutter up the User Profile with all this. > > Thanks for any ideas you can share. Sounds like you might want a models.OneToOneField() instead of a models.ForeignKey field. http://www.djangoproject.com/documentation/models/one_to_one/ Craig > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Is it secure "enough" to put login info in the session?
On Tue, Sep 8, 2009 at 10:20 PM, ristretto.rbwrote: > > Hi > > I want to have a guest concept. You get instant access to my app. > There are limits. But, you will be allowed to come back multiple > times before I require you to register. How do you plan to tell if the guest "came back"? The only reasonable mechanism I can think of is to use a session cookie (you can't rely on things like IP address ... like most folks with a home router, all the computers in my household will appear to have the same IP address to a service we contact, and the same would be true for most business situations). And even if you rely on a session cookie, your restrictions are easily bypassed by the user who simply clears their cookie cache. Until you can solve this problem reliably (good luck!), the implementation details are not really worth thinking about. But things like using a session cookie are no more or less secure for this use case than they are for the usual approach to keep a user logged on to a web app, other than the fact that you'd probably need to keep your session alive a lot longer. Craig PS: The typical solution I've seen for a "guest" concept is to offer only a limited subset of the overall functionality to non-registered users, with lots of teasers about "if you would only bother to register, you could do FOO and BAR and BAZ!". Example: ESPN's web site has a bunch of "freely available" stories accessible to anonymous users, but the (presumbably) good stuff requires a login. Figuring out the balance point is a challenge -- for me, for example, I'm not a fantasy football junkie, so the extra subscribers-only analysis doesn't have enough value for me to bother to register (or pay, as the case may be). > > When a user comes in as a guest, I will create a user with a bogus > username, password and email, and put the user_id in the session, so > that when the user comes back I can read it and restore saved state. > > I'm mildly concerned that it's unsafe to put the user_id in the > session. I can imagine a hacker faking that somehow, and getting > access to other guest accounts. I'm not sure the risk is that big, > and once users register, the risk goes down. But, I'm wondering if > this is at all foolhardy. Is there a better way to approach this? > > Perhaps a hash key or something that isn't sequentially too > guessable. Or some encryption. > > This guest concept has inherent security issues with shared computers: > labs, cafes, etc. The user will made aware of this when logging in as > Guest. Also there will be no sensitive or private data in this guest > account that if seen by another user would make much difference. > > Thanks for any insight > Gene > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Many-to-many column admin interface
On Thu, Aug 27, 2009 at 10:00 AM, Sven Richterwrote: > I found this thread: > http://stackoverflow.com/questions/660260/django-admin-form-for-many-to-many-relationship > on Stackoverflow, but when i try the suggested TabularInline thing i get the > error: > > has no ForeignKey to 'politlog.entry.models.Entries'> > At least with Django 1.0.x, the admin interface does not support many-to-many relationships on inlines -- it will always return an error like the one you got above. Indeed, the message is technically accurate, because m2m relationships get implemented as a separate table, so there is no direct relationship between the two. InlineModelAdmin works great for one-to-many but not for many-to-many. I'd also be interested in solutions to this, not having found anything in a bunch of Google searches. The alternative I'm planning on is having to hand-code some views, forms, and templates that let me do the right thing -- not a huge amount of work, but having admin do it for us would be way cool. Craig > Greetings > Sven --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---