Re: domains vs sub-domains

[Craig McClanahan]

On Mon, Nov 9, 2009 at 9:38 PM, Chris  wrote:
>
> 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

[Craig McClanahan]

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

[Craig McClanahan]

On Wed, Sep 16, 2009 at 7:15 AM, PlanetUnknown
 wrote:
>
> 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?

[Craig McClanahan]

On Tue, Sep 8, 2009 at 10:20 PM, ristretto.rb wrote:
>
> 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

[Craig McClanahan]

On Thu, Aug 27, 2009 at 10:00 AM, Sven Richter wrote:
> 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
-~--~~~~--~~--~--~---