Ben Sizer wrote: > Sorry to ask what must be a fairly common question, but I don't see a > common answer anywhere yet!
No problem. This is a question of personal taste, in my opinion. I use Elixir in some projects, and plain SQLAlchemy in others. I can explain a bit better by responding to the rest of your line of questioning below :) > I found writing out the model using the SQLAlchemy method reasonably > unpleasant, for 2 reasons: firstly, because of the unintuitive backref > stuff which seemed to allow a reference to be accidentally declared > twice under different names, and secondly because it specifies the > relationship values separately from the property values - this makes > reading the model.py to understand the model quite unintuitive. > > So I redid it in Elixir and it looks far more palatable, with my > objects having all their data in the same place and without any > extraneous mapping stuff. All, that is, apart from the auto-generated > Identity tables which were plain SA and which I didn't feel confident > enough to alter. This sounds familiar to many Elixir users who started with plain SQLAlchemy but wanted something that made their model have far fewer lines of code and boilerplate. > My questions are these: > > - Generally responses have been along the lines of "you can use plain > SA with Elixir", but can someone be more specific on how this is done? > Can I refer to a plain SA class from Elixir and have it work, or vice > versa? Is it more effort than just picking one of the two? There is a level of compatibility between plain SQLAlchemy and Elixir right now, and I know that Gaetan is making this compatibility fully bi-directional so that you can mix the two if needed. I don't know the details on what is possible now, but if you ask on the Elixir list, I bet you'll get a good answer on exactly what you can and cannot do. Also, feel free to experiment and report bugs on the Trac. Being able to mix the two is definitely a goal for Elixir, so you're never trapped within Elixir's limitations. > - Specifically, am I going to have problems with the Identity stuff > being in SA and the rest of my model being in Elixir? One or two of my > Elixir objects will need to access one or two of the plain SA models, > for certain. I just stopped using identity entirely since its design really makes it work best with SQLObject, and I don't like a lot of other things about it. There are plenty of alternatives, but I also know that there are people who use Identity with Elixir right now, and it works. You should be able to do this, and I believe that the example provided with Elixir still works. If it doesn't, let us know on the Elixir list, and we'll fix it. TurboGears support is also a goal for Elixir. I am hoping that TurboGears 2.0 will do away with identity entirely, and move to something a bit simpler and more extensible. > - People talk of there being things you can't practically do with > Elixir, but are quite vague on what this entails. Are these Turbogears > specific things or just object-relational specific things? I read that > the explicit mapping syntax of plain SA allows for mapping arbitrary > queries such as joins and so on, although at a glance it's not at > all obvious how. And docs.turbogears.org/1.0/SQLObjectVsSQLAlchemy > suggests that SO doesn't support multiple-column primary keys, but > I thought I read on this list recently that this isn't actually the > case. And I've no idea if Elixir supports them or not. So, just what > am I giving up by taking the simple approach? The only features of SQLAlchemy that might not work are in the *mapping* side of things, since other than the mapping and table declaration, you use Elixir just like you use regular SQLAlchemy. Elixir is just an alternate way to declare your tables, mappers, and classes. Once you have done this, you can create very powerful queries and arbitrary selects just like with plain SQLAlchemy. There are even statements in Elixir to let you pass whatever arguments you want to the table and mapper constructors, which gives you a ton of flexibility. The statement API gives you even more flexibility on top of that. I've heard a lot of people spreading misinformation about Elixir about things like compound primary keys, and I am not really sure why this is happening. Its kind of odd. I think its mostly to do with documentation and their initial reaction to the old DSL-syntax, which we now have replaced with a more familiar syntax for declaring fields and relationships. > I feel a bit stuck between using the easy and clean interface > that isn't recommended by TG, or using the complex and somewhat > obscure interface that is recommended by TG but nowhere near as well > documented as SQLObject used to be. My gut feeling is to bite the > bullet and switch it all to plain SA just to be on the safe side, but > it would be a shame to pull apart all those classes if it's ultimately > unnecessary. That seems like a huge waste of time. If you have something that works for you today, and you like it, stick with it. If you encounter problems down the road, let us know on the Elixir list, and we'll do our best to fix the problems or add the features you request. Some really cool stuff has been put into Elixir because users have given us great ideas. If you have questions, ask them on the list as well, and we'll do our best to answer them, and put the answers in the documentation. > It may be that I'm worrying for nothing and that changing from one to > the other later is simple, but then that would be useful information > to have as well. Hopefully there are answers to this and the other > questions. Personally, I think you are worrying for nothing. TurboGears doesn't tell you *not* to use Elixir, it just doesn't use it as the default for a variety of reasons. But, in the end, Elixir is just SQLAlchemy under the covers, and you can always drop down to the raw table objects if you need to. Good luck! I am hoping to have more inquisitive users like you pick up Elixir, in the hopes that we can really improve due to your feedback and contributions! -- Jonathan LaCour http://cleverdevil.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
