python sql query in django
I have three tables:
class Technology(models.Model):
technology = models.CharField(max_length=100, null=True,
blank=True )
def __unicode__(self):
return self.technology
class Meta:
ordering = ["technology"]
class Publication(models.Model):
pubtitle = models.TextField(null=True, blank=True)
def __unicode__(self):
return self.pubtitle
class Meta:
ordering = ["pubtitle"]
class Techpubcombo(models.Model):
technology = models.ForeignKey(Technology)
publication = models.ForeignKey(Publication)
The user selects a technology from the drop down menu on the web
page. The technology is retrieved
from the database table and then it must be used to retrieve the
publication attributes, by first going through the Techpubcombo table.
I wrote the select to retrieve the data for the html drop down box:
technology_list = Technology.objects.all().order_by('technology')
After the user makes a selection, the technology_id is retrieved:
technology_id = request.POST['technology_id']
t = get_object_or_404(Technology, pk=technology_id)
Now I need to use the technology_id to get to the publication
attributes
This is where I'm stuck.
I get error messages when I try to do something like:
pub=t.techpubcombo.publications_set()
Ana
--
http://mail.python.org/mailman/listinfo/python-list
Re: python sql query in django
On Feb 23, 11:31 am, Bruno Desthuilliers wrote: > May a écrit : > > > I have three tables: > > Actually - from Python's code POV - three Model classes. And actually, > since there's a very active, friendly and helpful django group on > googlegroups, you'd be better reposting your question there. > > (snip Django's ORM related question) The django users groups suggests using a manytomany field. That works well in the html template, but in the admin tables, the logic for the manytomany field applies to the wrong model and doesn't create a choice for the data entry people. I'm trying to write this without using the manytomany option. Just using the standard relational database model. I need to understand if python can do what I need to do. So far, I've not been successful with an answer in users groups. Ana -- http://mail.python.org/mailman/listinfo/python-list
Re: python sql query in django
On Feb 23, 1:00 pm, Steve Holden wrote: > May wrote: > > On Feb 23, 11:31 am, Bruno Desthuilliers > > wrote: > >> May a écrit : > > >>> I have three tables: > >> Actually - from Python's code POV - three Model classes. And actually, > >> since there's a very active, friendly and helpful django group on > >> googlegroups, you'd be better reposting your question there. > > >> (snip Django's ORM related question) > > > The django users groups suggests using a manytomany field. That works > > well in the html template, but in the admin tables, the logic for the > > manytomany field applies to the wrong model and doesn't create a > > choice for the data entry people. I'm trying to write this without > > using the manytomany option. Just using the standard relational > > database model. I need to understand if python can do what I need to > > do. So far, I've not been successful with an answer in users groups. > > I am sure if you explain in detail exactly what you want the admin to > present to your data entry people there are those on django-users who > can help you make it happen. That list *would* be the best place to get > an answer: this one mostly discusses the Python language in a more > generic manner. > > regards > Steve > -- > Steve Holden +1 571 484 6266 +1 800 494 3119 > Holden Web LLC http://www.holdenweb.com/ I may not stay with Django. I am seriously looking for whether python can read data from a relational database and send to an html template or do I always need some kind of wrapper/interface such as Rails or Django? If this is the wrong group to ask that question could you recommend another python group that could? Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: python sql query in django
On Feb 23, 12:48 pm, Bruno Desthuilliers wrote: > May a écrit : > (snip) > > > I may not stay with Django. > > Nope, but your question was about Django. > > > I am seriously looking for whether python > > can read data from a relational database > > Of course - as long as there's a Python adapter for your DB. > > > and send to an html template > > Of course - as long as it's either a Python templating system or there's > a Python binding for this system. > > > or do I always need some kind of wrapper/interface such as Rails > > Uh ? Rails is a Ruby framework. > > > or > > Django? > > No, you don't. If you prefer to reinvent the wheel on each and any part > of each an any web app you write, please feel free to do so. > > > If this is the wrong group to ask that question > > Which "that" question ?-) > > For question related to Django's ORM, the django group is indeed a > better place (as usual: always use the most specific group / maling list > / whatever first). If you have questions (like the above) that are about > Python itself, you're at the right place. Thanks for all your suggestions. From what I've experienced in Django and now that I know a little more about how Python functions, I will probably use a combination of PHP and Django, instead of trying to get Python to do the web portion of my project. Thanks again! -- http://mail.python.org/mailman/listinfo/python-list
Re: python sql query in django
On Feb 24, 10:36 am, "Diez B. Roggisch" wrote: > > Thanks for all your suggestions. From what I've experienced in Django > > and now that I know a little more about how Python functions, I will > > probably use a combination of PHP and Django, instead of trying to get > > Python to do the web portion of my project. Thanks again! > > That sounds like the worst idea. Django's ORM is good when used from > within django, because of all the additional goodies like the admin > interface. > > But if you are going to do the webfrontend using PHP, what part is left > for django? If it's only the ORM (for whatever you still use that > anyway), there are better alternatives - SQLAlchemy, and SQLObject, for > Python. They are more powerful and not interwoven with django. > > If you are going to hand-code the interface in PHP, I fail to see though > why you don't do that in Django directly. You are not forced to use the > Admin-interface. > > Diez Hello Diez, I think Django is fabulous for the admin-interface, a simple text search and template inheritance. I will use Django for all of those. What I'm not getting an answer to and cannot find an example of is a complex search, where I have to retrieve data from multiple tables, combine the data, remove the duplicates, etc between a web page and the database. The code that started this thread is only a small piece of the complex data retrieval I need to do. PHP is great for writing complex SQL queries right in the HTML template and I know exactly what it is doing. -- http://mail.python.org/mailman/listinfo/python-list
Re: A difficulty with lists
On Monday, August 6, 2012 3:50:13 PM UTC-4, Mok-Kong Shen wrote:
> I ran the following code:
>
>
>
> def xx(nlist):
>
>print("begin: ",nlist)
>
>nlist+=[999]
>
>print("middle:",nlist)
>
>nlist=nlist[:-1]
>
>print("final: ",nlist)
>
>
>
> u=[1,2,3,4]
>
> print(u)
>
> xx(u)
>
> print(u)
>
>
>
> and obtained the following result:
>
>
>
> [1, 2, 3, 4]
>
> begin: [1, 2, 3, 4]
>
> middle: [1, 2, 3, 4, 999]
>
> final: [1, 2, 3, 4]
>
> [1, 2, 3, 4, 999]
>
>
>
> As beginner I couldn't understand why the last line wasn't [1, 2, 3, 4].
>
> Could someone kindly help?
>
>
>
> M. K. Shen
The list nlist inside of function xx is not the same as the variable u outside
of the function: nlist and u refer to two separate list objects. When you
modify nlist, you are not modifying u. If you wanted the last line to be [1,
2, 3, 4], you could use the code below:
#BEGIN CODE
def xx(nlist):
print("begin: ",nlist)
nlist+=[999]
print("middle:",nlist)
nlist=nlist[:-1]
print("final: ",nlist)
return nlist
u=[1,2,3,4]
print(u)
u = xx(u)
print(u)
#END CODE
Notice that I changed two things. First, the function xx(nlist) returns nlist.
Secondly, u is reassigned to the result of xx(nlist).
--
http://mail.python.org/mailman/listinfo/python-list
Re: A difficulty with lists
On Monday, August 6, 2012 3:50:13 PM UTC-4, Mok-Kong Shen wrote:
> I ran the following code:
>
>
>
> def xx(nlist):
>
>print("begin: ",nlist)
>
>nlist+=[999]
>
>print("middle:",nlist)
>
>nlist=nlist[:-1]
>
>print("final: ",nlist)
>
>
>
> u=[1,2,3,4]
>
> print(u)
>
> xx(u)
>
> print(u)
>
>
>
> and obtained the following result:
>
>
>
> [1, 2, 3, 4]
>
> begin: [1, 2, 3, 4]
>
> middle: [1, 2, 3, 4, 999]
>
> final: [1, 2, 3, 4]
>
> [1, 2, 3, 4, 999]
>
>
>
> As beginner I couldn't understand why the last line wasn't [1, 2, 3, 4].
>
> Could someone kindly help?
>
>
>
> M. K. Shen
I've modified your code slightly so you can see what's happening with u in the
middle of function xx. Take a look:
u=[1,2,3,4]
def xx(nlist):
print("xx(u)\n")
print("At first, u and nlist refer to the same list")
print("nlist: %s u: %s\n" % (nlist, u))
nlist+=[999]
print("nlist+=[999]\n")
print("The list has been modified in place. u and nlist are still equal")
print("nlist: %s u: %s\n" %(nlist, u))
nlist=nlist[:-1]
print("nlist=nlist[:1]\n")
print("Now nlist refers to a new list object in memory that was created by")
print("taking a slice of u. u and nlist are no longer equal.")
print("nlist: %s u: %s" %(nlist, u))
xx(u)
Here's the output:
xx(u)
At first, u and nlist refer to the same list
nlist: [1, 2, 3, 4] u: [1, 2, 3, 4]
nlist+=[999]
The list has been modified in place. u and nlist are still equal
nlist: [1, 2, 3, 4, 999] u: [1, 2, 3, 4, 999]
nlist=nlist[:1]
Now nlist refers to a new list object in memory that was created by
taking a slice of u. u and nlist are no longer equal.
nlist: [1, 2, 3, 4] u: [1, 2, 3, 4, 999]
Thank you, Rob Day, for explaining a some of what's happening behind the scenes.
--
http://mail.python.org/mailman/listinfo/python-list
Re: A difficulty with lists
On Wednesday, August 15, 2012 8:21:22 PM UTC-4, Terry Reedy wrote: > On 8/15/2012 5:58 PM, Rob Day wrote: > > Yeah, my apologies for any confusion I created. Although I suppose my > explanation would be somewhat true for immutable objects since they can't be > modified in-place (any modification at all would cause the creation of a new > immutable object right?), I now understand that it is completely and totally > wrong for mutable objects. Thanks for the in-depth explanations, Terry and Rob. I feel like I have a much more solid grasp of what's going on behind the scenes after your analysis. > > > Madison May wrote: > > > The list nlist inside of function xx is not the same as the variable > > > u outside of the function: nlist and u refer to two separate list > > > objects. When you modify nlist, you are not modifying u. > > > <http://mail.python.org/mailman/listinfo/python-list> > > > > This is confused and wrong. The parameter *name* 'nlist' of function xx > > is not the same as the *name* 'u' outside the function. The call xx(u) > > binds nlist to the same object that u is bound to. At that point, the > > two name *are* bound to the same list object. The statement > > "nlist+=[999]" dodifying nlist *does* modify u. The subsequent > > assignment statement "nlist=nlist[:-1]" rebinds 'nlist' to a *new* list > > object. That new object gets deleted when the function returns. So the > > rebinding is completely useless. > > > > This sequence, modifying the input argument and then rebinding to a new > > object, is bad code. > > > > > Well - that's not quite true. Before calling the function, u is [1, 2, > > > 3, 4] - but after calling the function, u is [1, 2, 3, 4, 999]. This is > > > a result of using 'nlist += [999]' - the same thing doesn't happen if > > > you use 'nlist = nlist+[999]' instead. > > > > > > I'm not completely aware of what's going on behind the scenes here, but > > > > you got it right. > > > > > I think the problem is that 'nlist' is actually a reference to a list > > > object - it points to the same place as u. > > > > Calling a python function binds parameter names to argument objects or > > (for *args and **kwds parameters) a collection based on argument objects. > > > > > When you assign to it within > > > the function, then it becomes separate from u - which is why nlist = > > > nlist+[999] and nlist = nlist[:-1] don't modify u - but if you modify > > > nlist in place before doing that, such as by using +=, then it's still > > > pointing to u, and so u gets modified as well. > > > > > > -- > > Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Top-posting &c. (was Re: [ANNC] pybotwar-0.8)
> And FWIW, I add my voice to those who prefer to read replies > > underneath the original text. Even if Mark were the only person vocal > > enough to complain, you can still rest assured that there are many > > more who agree. You've now heard from quite a few regular posters; > > there are probably several *hundred* lurkers who feel the same way, > > but do not post (possibly because they cannot). Also, these mails get > > archived all over the internet, so a generation not yet born can read > > and be either enlightened or irritated, as the case may be. > > > > ChrisA As a lurker, I agree completely with Chris's sentiments. -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
[EMAIL PROTECTED] (Alex Martelli) writes: > In my opinion (and that of several others), the best way for Python to > grow in this regard would be to _lose_ lambda altogether, since named > functions are preferable Why? I find the ability to create unnamed functions on the fly to be a significant benefit when coding in Common Lisp. Regards, Patrick S P Engineering, Inc.| The experts in large scale distributed OO | systems design and implementation. [EMAIL PROTECTED]| (C++, Java, Common Lisp, Jini, CORBA, UML) -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
[EMAIL PROTECTED] (Alex Martelli) writes: >> >> In my opinion (and that of several others), the best way for >> >> Python to grow in this regard would be to _lose_ lambda >> >> altogether, since named functions are preferable >> > >> > Why? I find the ability to create unnamed functions on the >> > fly to be a significant benefit when coding in Common Lisp. >> >> 1. They don't add anything new to the language semantically >>i.e. you can always used a named function to accomplish the same >>task as an unnamed one. Sure, but it won't necessarily be as expressive or as convenient. >> 2. Giving a function a name acts as documentation (and a named >>function is more likely to be explicitly documented than an >>unnamed one). This argument is pragmatic rather than >>theoretical. Using lambda in an expression communicates the fact that it will be used only in the scope of that expression. Another benefit is that declaration at the point of use means that all necessary context is available without having to look elsewhere. Those are two pragmatic benefits. >> 3. It adds another construction to the language. That's a very minimal cost relative to the benefits. You haven't made your case for named functions being preferable. Regards, Patrick S P Engineering, Inc.| The experts in large scale distributed OO | systems design and implementation. [EMAIL PROTECTED]| (C++, Java, Common Lisp, Jini, CORBA, UML) -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
[EMAIL PROTECTED] (Alex Martelli) writes: > ...an alleged reply to me, which in fact quotes (and responds to) > only to statements by Brian, without mentioning Brian... > > Mr May, it seems that you're badly confused regarding Usenet's > quoting conventions. It seems that someone pisses in your cornflakes nearly every morning. For the record, I was attempting to respond to your post which I only saw quoted in another message. Please excuse any accidental misquoting. >> Using lambda in an expression communicates the fact that it >> will be used only in the scope of that expression. Another benefit >> is that declaration at the point of use means that all necessary >> context is available without having to look elsewhere. Those are >> two pragmatic benefits. > > You still need to look a little bit upwards to the "point of use", > almost invariably, to see what's bound to which names -- so, you DO > "have to look elsewhere", nullifying this alleged benefit -- looking at > the def statement, immediately before the "point of use", is really no > pragmatic cost when you have to go further up to get the context for all > other names used (are they arguments of this function, variables from a > lexically-containing outer function, assigned somewhere...), which is > almost always. It appears that you write much longer functions than I generally do. Requiring that all functions be named adds even more to the clutter. > And if you think it's an important pragmatic advantage to limit > "potential scope" drastically, nothing stops you from wrapping > functions just for that purpose around your intended scope Or, I could just use a language that supports unnamed functions. > Your "pragmatic benefits", if such they were, would also apply to the > issue of "magic numbers", That claim is, frankly, silly. A function is far more understandable without a name than a value like 1.19 in isolation. The situations aren't remotely comparable. >> >> 3. It adds another construction to the language. >> >> That's a very minimal cost relative to the benefits. > > To my view of thinking, offering multiple semantically equivalent > ways (or, perhaps worse, "nearly equivalent but with subtle > differences" ones) to perform identical tasks is a *HUGE* conceptual > cost: I like languages that are and stay SMALL and SIMPLE. Like Scheme? Regards, Patrick S P Engineering, Inc.| The experts in large scale distributed OO | systems design and implementation. [EMAIL PROTECTED]| (C++, Java, Common Lisp, Jini, CORBA, UML) -- http://mail.python.org/mailman/listinfo/python-list
ImportError: DLL load failed
I'm having trouble importing when I run in Python. The hello world program passes the test during the bjam build but gives an error about loading the dll when I import from a python script. first the test from running bjam. ...patience... ...found 1915 targets... ...using 1 temp target... ...updating 2 targets... ...using hello_ext.pyd... capture-output bin\hello.test\msvc-8.0express\debug\threading-multi\hello 1 file(s) copied. **passed** bin\hello.test\msvc-8.0express\debug\threading-multi\hello.test ...updated 2 targets... then trying to run the script from python I copied the pyd file and the rest of the output dir to c:\python25\dlls C:\Program Files\boost\boost_1_35_0\libs\python\example\tutorial>python hello.py Traceback (most recent call last): File "hello.py", line 6, in import hello_ext ImportError: DLL load failed: This application has failed to start because the a pplication configuration is incorrect. Reinstalling the application may fix this problem. Thanks for any help Tony Reply Forward -- http://mail.python.org/mailman/listinfo/python-list
