Re: Proposal: Generic Pagination
On 8/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Something like this? > > http://www.djangosnippets.org/snippets/378/ > I extended a different snippet to do what I wanted. Posted it just now at [1]. I do think that this needs to be looked at, for my first django project, this was one of the major stumbling blocks for me. (Which I think is about as good of an endorsement for django as any other) [1] http://www.djangosnippets.org/snippets/394/ Paul Davis --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Generic Pagination
On 8/27/07, Iapain <[EMAIL PROTECTED]> wrote: > > > http://www.djangosnippets.org/snippets/378/ > Not really > > > http://www.djangosnippets.org/snippets/394/ > bit closer (should have used query string ?p=1 instead of /page/1) > I definitely wrestled with this. I ended up going without the query string cause from the examples i saw it looked like the 'django way' of doing things. > But still I prefer the way django.contrib.admin is doing. The core > question is it should be included in django standard package? I > implemented one the way django.contrib.admin is doing. > http://dpaste.com/17864/ > > Deepak > > And I vote yes to including a version similar to yours. Paul Davis --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
syncdb not running custom sql in a transaction
I'm having a bit of a problem using the appname/sql/model.sql custom sql files. Running: $ python manage.py syncdb root Gives: Installing custom SQL for root.Status model Installing custom SQL for root.Target model Installing custom SQL for root.Reference model Installing custom SQL for root.Sequence model Installing custom SQL for root.Upload model Installing custom SQL for root.Library model Failed to install custom SQL for root.Library model: insert or update on table "root_upload" violates foreign key constraint "lib_id_refs_id_6bb65980" DETAIL: Key (lib_id)=(2) is not present in table "root_library". Traceback (most recent call last): File "manage.py", line 11, in ? execute_manager(settings) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages/django/core/management/__init__.py", line 180, in execute_manager utility.execute(argv) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages/django/core/management/__init__.py", line 124, in execute command.execute(*args[1:], **options.__dict__) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages/django/core/management/base.py", line 34, in execute output = self.handle(*args, **options) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages/django/core/management/base.py", line 118, in handle return self.handle_noargs(**options) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages/django/core/management/commands/ syncdb.py", line 105, in handle_noargs transaction.rollback_unless_managed() File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages/django/db/transaction.py", line 145, in rollback_unless_managed connection._rollback() File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages/django/db/backends/__init__.py", line 24, in _rollback return self.connection.rollback() psycopg2.InterfaceError: connection already closed But running: $ python manage.py sqlcustom root | psql eureka Completes wihtout errors. So, I'm fairly certain that the custom sql is not being run in a single transaction like I would think it should if I can't specificaly order my scripts so that I populate tables that are referenced by foreign keys first. Plus, I'd assume this is a big reason why all the constraints are deferred too. So, anyone have any insights? Thanks, Paul Davis --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: syncdb not running custom sql in a transaction
On 9/5/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 9/6/07, Paul Davis <[EMAIL PROTECTED]> wrote: > > > > I'm having a bit of a problem using the appname/sql/model.sql custom > > sql files. > ... > > But running: > > $ python manage.py sqlcustom root | psql eureka > > > > Completes wihtout errors. So, I'm fairly certain that the custom sql > > is not being run in a single transaction like I would think it should > > if I can't specificaly order my scripts so that I populate tables that > > are referenced by foreign keys first. > > You are correct in that there is no transaction management around the > custom loaded SQL. If we were to add transaction management, I agree > that the best approach would be to wrap the entire custom SQL block in > a single transaction. However, I'm not completely convinced this is a > good idea. Your custom SQL script could include BEGIN/END statements. > It could include statements that imply a transaction end. In short, > there is no way to guarantee that the 'single transaction' guarantee > could ever be enforced. > > I would also suggest that you look at why you are using custom SQL. > The 'current best practice' is that custom SQL should only be used for > table modifications - adding constraints, new indicies, new non-django > columns, etc. If you want to insert data - the sort of thing that > causes key errors like the one you describe - then you should be using > fixtures. All fixtures _are_ loaded as a single transaction, so errors > of the type you describe are avoided. > > > Plus, I'd assume this is a big reason why all the constraints are > > deferred too. > > Correct. > > Yours, > Russ Magee %-) > > > > I ended up running into the issue of not being able to install a plpgsql function from the custom sql scripts so I rearanged alot of how I was doing this stuff. I ended up putting all of my data into a fixture as well. I think the biggest issue is the fact that: $ python manage.py sqlcustom appname gives sql thats in a transaction. It was confusing to have the two different behaviors. Thanks again, Paul Davis --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution status
Hey everyone, Hopefully I've read up enough to jump into this conversation, but if I haven't then feel free to blast me as is appropriate. If I offend anyone, try and remember I'm only trying to show my opinions on different issues. And you're more than welcome to fire back. ;) So for some reason schema evolution is causing quite a bit of controversy among the django crowd. At first I couldn't figure out why until I started reading about the large range of ideas for implementation. But then, the more I read, the more confused I became again. As near as I can tell these are the main issues that don't seem to be resolved: 1. Balancing ease of use with power of use (Ie, Alice vs. Carol) 2. Level of versioning: Model vs. Application vs. Entire database 3. Application of versions: v1 -> v2 -> v3 =? v1 -> v3 4. How do we represent a migration from state 1 to state 2 These are ordered near as I can tell in roughly the order we have to overcome to have something merged into the trunk. #1 is a nobrainer. We want both. And we won't settle for less. #2 There is alot of talking around this issue but I haven't seen anyone take it full on. We have to version the entire schema as a single object. Anyone in doubt, I refer to SVN's repository wide versioning vs CVS's file specific versioning. #3 There are those that think v1->v2->v3 == v1->v3. I am not one of those people. A database is defined (in my mind) by its schema and the data it contains. Migrations are non-linear. Each migration script must be run. #4 This is minor, but I felt it necessary to say that we're obviously going to need python scripts to go from state to state. And custom sql would be easy to integrate. === So those are the main points near as I can tell. Now I'll go over some of the popular topics I saw: 1. The use of introspection: Will introspection be used? Of course. Will it be *all* thats used? Of course not. Introspection will be useful for testing state. It is possible that we could also add some 'best-guesses' on how to go from one state to the next, whether someone chooses to accept our guesses without checking is their problem (Alice). Obviously spitting out things like "I cannot guess what needs to be done" would be useful. I tend to think the django crowd would go along with this sort of thing. 2. The famous 'aka' syntax. For those of you out there saying that this is absurd and doesn't provide any information, I'm thankful. The syntax is horrible. Remember my quip about SVN vs. CVS versioning? This is like some ultra brain dead system that trys to version individual lines in a file. I mean, not even CVS is that bad. = In order to keep things short this is all I'm gonna say for now. This email is already too long. Thanks, Paul Davis --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution status
On 9/27/07, Derek Anderson <[EMAIL PROTECTED]> wrote: > > Paul Davis wrote: > > > > As near as I can tell these are the main issues that don't seem to be > resolved: > > > > 1. Balancing ease of use with power of use (Ie, Alice vs. Carol) > > 2. Level of versioning: Model vs. Application vs. Entire database > > 3. Application of versions: v1 -> v2 -> v3 =? v1 -> v3 > > 4. How do we represent a migration from state 1 to state 2 > > > #1 is a nobrainer. We want both. And we won't settle for less. > > agreed. this is why fingerprinting, versioning and controlled > deployment scripts are all optional in my implementation. (as i feel > they must be to support alice) > I think the main difference here is how we're wanting to provide for Alice here. You seem to want to remove the 'dificult' parts for Alice. I'd just make those parts automagically generated. I also wonder if making scripts optional isn't an effect of some of your other design decisions. > > #2 There is a lot of talking around this issue but I haven't seen > > anyone take it full on. > > We have to version the entire schema as a single object. Anyone in > > doubt, I refer to SVN's repository wide versioning vs CVS's file > > specific versioning. > > i agree that at _least_ applications need to be versioned together. i > lean towards agreeing that we should version entire schemas, but w/ > django not having any existing inter-app dependency mechanism (other > than they just won't work), i was reluctant to mandate it. mostly > agree, but i think the ramifications need to be better thought out > before we push it on anyone. > This is a pretty good point about app dependancies. Although I think having a dependancy tracker here isn't required by the migration, but would help with errors that would invariably crop up when a migration script ran outside the installed apps setting. > > #3 There are those that think v1->v2->v3 == v1->v3. I am not one of > > those people. > > A database is defined (in my mind) by its schema and the data it > > contains. > > i think it depends on who you are. for alice at least, can you agree it > will be true? for the majority of apps/developers too, i'd argue. but > for disburse deployments, i've conceded before that support needs to be > there for v1->v2->v3. (and it is supported via my controlled deployment > scripts) > No I sure won't agree on this. Given two identical databases, and two different people running the migration scripts, the resulting databases should be equal. And if thats not true simply because of *when* they ran the scripts then the system would be broken. > > Migrations are non-linear. > > thank $DEITY someone else said this. :) imho any controlled > deployment system that _only_ supports lists of sequential versions is DOA. > I think this is related to who we're designing for. You seem to be designing for Alice. I want to design for Carol. Of course I'm running my thoughts through the "Will this prevent us from abstracting things for Alice" but she's not my primary concern. Specifically, whats to prevent us from requiring sequential versions that have a script at each step? Nothing. We just autogenerate the scripts with our guesses and Alice trusts them. > > So those are the main points near as I can tell. Now I'll go over some > > of the popular topics I saw: > > > > 1. The use of introspection: > > Will introspection be used? Of course. Will it be *all* thats used? Of > > course not. > > agreed, but i think the controversy is over using introspection to > _generate_ our guesses. (heck even syncdb uses introspection - noone's > arguing we shouldn't use any) > I'm all for using introspection to generate guesses. But only in cases where we can reasonably make that guess. (At this point I'm assuming that trivial 'Alice' changes will generally be guessable) > > 2. The famous 'aka' syntax. For those of you out there saying that > > this is absurd and doesn't provide any information, I'm thankful. The > > syntax is horrible. Remember my quip about SVN vs. CVS versioning? > > This is like some ultra brain dead system that trys to version > > individual lines in a file. I mean, not even CVS is that bad. > > you're confused as to it's purpose. it is certainly *not* an attempt to > version anything. it's there as a necessary hint to the guess_generation > routine. i think everyone acknowledges we need some sore of a hinting > syntax on top of the version tracking if we want
Django + SQL Alchemy
Before anyone gets to excited, I'm going to state up front that I have *not* replaced django's ORM. But I do have a small project that gives proof of concept for automatically integrating SQL Alchemy ORM into the Django ORM. I've been kicking the idea around for a bit, and after going through the code I felt it was fairly hopeless to actually try and replace the entire Django ORM with an sqlalchemy back end. Major key points: (remember this is PoC so suggestions are indeed welcome) SA = SQLAlchemy 1. SA creates its Table objects using reflection 2. SA ORM classes are dynamically created 3. SA ORM classes are directly importable via tranquil.models.* 4. I haven't got the ability to fully configure the setup of SA tables, ORM classes, and mappers yet. This is planned, but I felt like it wasn't important for PoC 5. Currently, SA reflection happens every time the server starts. Obviously, caching this is on the ToDo list 6. All of this is provided by an external app with no patches to Django itself. Project Page: http://code.google.com/p/tranquil/ Example views.py: http://tranquil.googlecode.com/svn/trunk/proj_name/app_name/views.py Basic usage: Assuming tranquil is in the installed apps, just do: from tranquil.models.app_name import ModelName ModelName is the SQLAlchemy ORM object which means its pure SQLAlchemy from there. Any feedback is welcome. If there's enough interest I'll move forward with filling out the corners. Thanks, Paul Davis --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django + SQL Alchemy
Ben, I contemplated something like this, but I assumed that field properties would clash. For instance, after the call to mapper(...) you would no longer have access to Django ORM fields with the Model.field syntax (as they would be replaced by SA's). So what I did was this: To get Django models: from django.contrib.auth.models import User To get SA models: from tranquil.models.auth import User The other thing I wasn't so sure about in combining the two is if that would require each page view to grab 2 connections to the db. Once for the Django ORM and once for the SA ORM. There's a lot of implicit stuff I haven't totally groked (specifically, if the connection grabbing is lazy or not) Anyway, I'm gonna take a closer look at the project the Jeroen guy is working on to see how it works and if there's anything I can use. Judging by reading through the description at the URL you posted it seems quite a bit more clunky to use, but he does do some of the things I had initially planned on doing. Thanks for the heads on the project. I hadn't heard of it. Paul Davis On 10/4/07, Ben Ford <[EMAIL PROTECTED]> wrote: > Hi Paul, > > I'd love to have time to play with this, but I don't at the moment. It's > something I've been interested in for a while though, and also something > that I want to take a long hard look at pretty soon. Have you seen: > http://jeroen.concept-q.com/projects/djangoalchemy/? Maybe > something you could look at in the spirit of DRY if you're both doing the > same thing. > > How do you feel about mapping Tables directly to django Models...? I.E: > > db_table = ._meta.db_table > sastring = (I have a function to build this > from settings.py ) > engine = create_engine(sastring) > sa_table = Table(db_table, engine, autoload=True) > mapper(, sa_table) > > You can now use .c to get access to all of the SA stuff, and do > funky things with joins and what-not that you can't with django ORM. But all > of the objects that the resulting query returns are Model instances so all > of your django functionality (admin, etc) still works. This is kinda off the > top of my head, and I've only used it superficially with no testing at all, > but on first inspection it appears to work. what do you think? > > Ben > > > On 05/10/2007, Paul Davis <[EMAIL PROTECTED]> wrote: > > > > > > Before anyone gets to excited, I'm going to state up front that I have > > *not* replaced django's ORM. > > > > But I do have a small project that gives proof of concept for > > automatically integrating SQL Alchemy ORM into the Django ORM. I've > > been kicking the idea around for a bit, and after going through the > > code I felt it was fairly hopeless to actually try and replace the > > entire Django ORM with an sqlalchemy back end. > > > > Major key points: (remember this is PoC so suggestions are indeed welcome) > > > > SA = SQLAlchemy > > > > 1. SA creates its Table objects using reflection > > 2. SA ORM classes are dynamically created > > 3. SA ORM classes are directly importable via tranquil.models.* > > 4. I haven't got the ability to fully configure the setup of SA > > tables, ORM classes, and mappers yet. This is planned, but I felt like > > it wasn't important for PoC > > 5. Currently, SA reflection happens every time the server starts. > > Obviously, caching this is on the ToDo list > > 6. All of this is provided by an external app with no patches to Django > itself. > > > > Project Page: http://code.google.com/p/tranquil/ > > Example views.py: > > > http://tranquil.googlecode.com/svn/trunk/proj_name/app_name/views.py > > > > Basic usage: > > Assuming tranquil is in the installed apps, just do: > > > > from tranquil.models.app_name import ModelName > > > > ModelName is the SQLAlchemy ORM object which means its pure SQLAlchemy > > from there. > > > > Any feedback is welcome. If there's enough interest I'll move forward > > with filling out the corners. > > > > Thanks, > > Paul Davis > > > > [EMAIL PROTECTED] > > +6281317958862 > > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django + SQL Alchemy
SmileyChris, At the moment, I'm using the class_prepared signal to gather all loaded models. Theoretically I could use this to attach an SA attribute. Are there use cases out there where you'd want to use *both* the Django and SA ORM's side by side? To me it makes more sense to import one or the other depending on what you plan on doing. For instance all of my code will use just the SA models, but the admin will still use the Django models. Paul On 10/5/07, SmileyChris <[EMAIL PROTECTED]> wrote: > > > > On Oct 6, 5:24 am, "Paul Davis" <[EMAIL PROTECTED]> wrote: > > Ben, > > > > I contemplated something like this, but I assumed that field > > properties would clash. For instance, after the call to mapper(...) > > you would no longer have access to Django ORM fields with the > > Model.field syntax (as they would be replaced by SA's). > > Could you use the post_init signal to attach a LazySAModel object as > an SA (or something) property of all newly created Django models? > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django + SQL Alchemy
Ben, If I understand you right, you're arguing to merge the SA and Django models so that we can use Django's reverse lookups. SA supports reverse lookups and I'm just getting started on implementing these automagically by introspecting the django models. I'm still not convinced that overriding Django model fields with SA model fields is a good idea. There seems to be quite a bit of code in the Django fields for dealing with forms and what not. I'm assuming that this is an artifact of oldfields and will be removed eventually, but until then all code depending on oldfields would choke. Something I'm trying to avoid. The only reasons that I can come up with supporting using Django models as a base would be to try and automatically use the extra methods defined for a model or *maybe* using the custom managers. Both of these 'features' seem like they would present an endless can of worms because of all the implicit relationships between the django models, fields, and managers. At the moment, I'm trying to keep things as straightforward as possible so its easy to switch back and forth between the two model styles. Anyway, thanks for your thoughts. Hopefully I can introspect all the relationships and have back references working automatically before I go home tonight. Paul On 10/5/07, Ben Ford <[EMAIL PROTECTED]> wrote: > Hi Paul, > > I don't think it would entail two db lookups, but like I said I haven't > tested it. SA will be instantiating a django Model, but it will be filling > in it's data from the database, so there should be no lookup required by > django. > > It does overwrite the field as far as I know, but that shouldn't matter in > because all you get from a field is that field's value from the database > anyway. The django ORM is still usable... So you still get the ability to do > reverse related lookups and such, even from objects in a list returned by > SA: i.e. if you have the following > > class Alarm(models.Model): > > ran_obj = models.ForeignKey(RANObject, related_name='alarms') > . > > and you get a list of RANObjects from some complicated lookup that you use > SA for, then you should still be able to do: > > ran_ob.alarms.all() > > This is one case where I could envisage using SA and django ORM side by > side. > That way you won't have to mess with any of your views/admin/django core > functionality, as the underlying objects are still just django models. > > What do you think? > > Ben > > On 06/10/2007, Paul Davis <[EMAIL PROTECTED]> wrote: > > > > SmileyChris, > > > > At the moment, I'm using the class_prepared signal to gather all > > loaded models. Theoretically I could use this to attach an SA > > attribute. > > > > Are there use cases out there where you'd want to use *both* the > > Django and SA ORM's side by side? To me it makes more sense to import > > one or the other depending on what you plan on doing. For instance all > > of my code will use just the SA models, but the admin will still use > > the Django models. > > > > Paul > > > > On 10/5/07, SmileyChris < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > On Oct 6, 5:24 am, "Paul Davis" <[EMAIL PROTECTED]> wrote: > > > > Ben, > > > > > > > > I contemplated something like this, but I assumed that field > > > > properties would clash. For instance, after the call to mapper(...) > > > > you would no longer have access to Django ORM fields with the > > > > Model.field syntax (as they would be replaced by SA's). > > > > > > Could you use the post_init signal to attach a LazySAModel object as > > > an SA (or something) property of all newly created Django models? > > > > > > > > > > > > > > > > > > > > > > > > > -- > Regards, > Ben Ford > [EMAIL PROTECTED] > +6281317958862 > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django + SQL Alchemy
Norjee, You touched on a point I've been trying to figure out for a bit. Using SA is inevitably going to lead to having people maintaining two sets of models. This was a bit of a concern for me. My goal here is to make the SA models as minimal as possible. The end idea will be to let people specify SA models just to override what would be automatically created by my app. Ie, my code did something wrong. So they just specify it by hand and all is good (and they submit a bug, and I fix it, and then they're back to no extra SA code). Granted I think there might end up being bits that I won't be able to introspect from the DB and/or the django models. (legacy databases with some funky setup). As to returning data as a list of dicts or some such, this isn't a feature that I'm going to worry about. I can't say that I've done any testing on this, but if you're worried about the overhead of creating objects for each row, then maybe you should look into using the raw DB-API to get your data. Paul Davis On 10/6/07, Norjee <[EMAIL PROTECTED]> wrote: > > Hi from the Jeroen guy ;) > > As you can see my version of mixing sqlalchemy and django is a bit > dormant. At the very least it needs some changes to work with > sqlalchemy .4. Besides my code is a bit sloppy, as much of the > translation django syntax -> sqlalchemy syntax was trial and error. > > What my solution basically does is translate the django mapping to > sqlalchemy mapping, give the django model an inner class which will > then be the sqlalchemy model. > http://jeroen.concept-q.com/projects/djangoalchemy/readme.txt > explains it nicely. > > For now this isn't too exiting, however, it means you have only one > set of model to maintain, all the relations and custom names of fields > will be the same in the sqlalchemy model. Moreover, it should be > possible to use custom methods from the django model in the sqlalchemy > model. It is my guess that with little effort it should be possible to > emit the signals django models send as well.. > > One thing that does not work yet are generic relations. Those seem > pretty django specific. > > One more advanced thing i would REALLY love to see is some form of > lazy object initialisation. Both the django and sqlalchemy ORM > immediately create an object, while often the basic dictionary of rows > would suffice (when you query for the last 10 posts, you really don't > need the post object, only the rows with post id, title, and time. > Only when you start manipulating a single post, you need the object to > call, for example, the save method. It seems to me that once an > unknown method is being called, it is a nice time to "upgrade" the > simple dictionary to a full blown object with save method..) However, > i'm a bit clueless how to implement this ;) > > Anyway, good luck with the django + sqlalchemy solution. "Steal" as > many ideas you want. The development of my thingy will probably go > slow, as the main reason for publishing such an alpha status solution > was to get others to think on getting sqlalchemy to work inside > django. (Sadly (or fortunately as it means the django ORM _is_ > sufficient for all) there seems not much interest in blending > sqlalchemy in django, so don't expect lots of (external) need for your > project) > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django + SQL Alchemy
Quick update: I've got this working so that Django models are automatically introspected to create all the same backrefs for use in SA that you would have access to in Django. SA Table's and Mapper's can be overridden in your app so you can add custom methods to your models. Due to popular demand, you can use your Django models as the ORM objects. I'm in the process of filling out some documentation on the wiki. If anyone has any comments or suggestions I'd like to hear them. All in all, adding SQLAlchemy to your Django project takes three lines of code. Paul Davis On 10/6/07, Ben Ford <[EMAIL PROTECTED]> wrote: > Hi Paul, > > Model field values are just the value of that field in the database, *not* > the field itself. The fields themselves are atored in _meta.fields and > _meta.many_to_many. The field does all of it's work by looking at the model, > i.e. getattr(model_instance, field_name). > > So it makes no difference if you change the value. Therefore when a model is > created, it should make no difference if the field value are set by django > or SA... as long as they are the same then there's no problem. > > This is a bit of a superficial explanation, as of course it makes no > allowance for the case where the db_column has been set in the field and is > therefore different to the attribute name applied to the model. However I > think the theory is sound. > > Ben > > > > On 07/10/2007, Paul Davis <[EMAIL PROTECTED]> wrote: > > > > Ben, > > > > If I understand you right, you're arguing to merge the SA and Django > > models so that we can use Django's reverse lookups. > > > > SA supports reverse lookups and I'm just getting started on > > implementing these automagically by introspecting the django models. > > > > I'm still not convinced that overriding Django model fields with SA > > model fields is a good idea. There seems to be quite a bit of code in > > the Django fields for dealing with forms and what not. I'm assuming > > that this is an artifact of oldfields and will be removed eventually, > > but until then all code depending on oldfields would choke. Something > > I'm trying to avoid. > > > > The only reasons that I can come up with supporting using Django > > models as a base would be to try and automatically use the extra > > methods defined for a model or *maybe* using the custom managers. > > > > Both of these 'features' seem like they would present an endless can > > of worms because of all the implicit relationships between the django > > models, fields, and managers. > > > > At the moment, I'm trying to keep things as straightforward as > > possible so its easy to switch back and forth between the two model > > styles. > > > > Anyway, thanks for your thoughts. Hopefully I can introspect all the > > relationships and have back references working automatically before I > > go home tonight. > > > > Paul > > > > On 10/5/07, Ben Ford <[EMAIL PROTECTED]> wrote: > > > Hi Paul, > > > > > > I don't think it would entail two db lookups, but like I said I haven't > > > tested it. SA will be instantiating a django Model, but it will be > filling > > > in it's data from the database, so there should be no lookup required by > > > django. > > > > > > It does overwrite the field as far as I know, but that shouldn't matter > in > > > because all you get from a field is that field's value from the database > > > anyway. The django ORM is still usable... So you still get the ability > to do > > > reverse related lookups and such, even from objects in a list returned > by > > > SA: i.e. if you have the following > > > > > > class Alarm(models.Model): > > > > > > ran_obj = models.ForeignKey(RANObject, related_name='alarms') > > > . > > > > > > and you get a list of RANObjects from some complicated lookup that you > use > > > SA for, then you should still be able to do: > > > > > > ran_ob.alarms.all() > > > > > > This is one case where I could envisage using SA and django ORM side by > > > side. > > > That way you won't have to mess with any of your views/admin/django core > > > functionality, as the underlying objects are still just django models. > > > > > > What do you think? > > > > > > Ben > > > > > > On 06/10/2007, Paul Davis < [EMAIL PROTECTED]&g
Re: Adding a hook for pre-runtime setup (ticket #5685)
Two things. The preruntime hook is a pretty good idea. Something to think about though is providing a way to add callbacks to this hook that is independant of settings.py. Otherwise 3rd party apps that want the functionality would require changes to the settings.py beyond the INSTALLED_APPS tuple. Granted, some might argue that as long as we're changing the INSTALLED_APPS we might as well change the hooks tuple. Anyway, just a thought. Second, It might be possible to add a post-model instantiation signal fairly easily in django.db.models.loading.AppCache._populate(). I'm not 100% certain on this, but its there and seems like the logical place to put a signal. Paul On 10/8/07, Andrew Durdin <[EMAIL PROTECTED]> wrote: > > On 10/8/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > > On Mon, 2007-10-08 at 09:15 -0400, Benjamin Slavin wrote: > > > > > > My immediate thought is that we could allow pre-model instantiation > > > (as proposed in the ticket) and post-model instantiation hooks > > > > I don't think we want to do this. Signals exist already for exactly this > > purpose. Setting up a way to install functions prior to models being > > imported but after settings are imported allows us to cover all cases > > because you can install class_prepared handlers, as Andrew suggested. > > Some months ago I asked whether a signal could be sent after all > models are prepared (but before requests were handled). The reasons > behind this were complex, but it boiled down to being able to examine > a 'Search' attribute of all models to determine what properties needed > to be stored in a full text index. > > This can be done with lazy loading and a class_prepared hook, but I > would much prefer to have the search index configuration happen at a > predictable time. If this could be done with a post-model signal it'd > be great, but I can't see how such a signal would be possible without > modifying Django's startup rather a bit. > > A. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Adding a hook for pre-runtime setup (ticket #5685)
> Fortunately, a pre-runtime hook gives anybody who wants it the ability > to add this signal for their own use anyway, so the initial problem > solution solves everything. > Good point. You win this round... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
