On Mon, Aug 24, 2009 at 21:46, Johannes Janssen<[email protected]> wrote: > Gaetan de Menten schrieb: >>> I assume that you agree that having "resolve_root" on a per-entity basis >>> makes sense.
>> Hmm no. Seems like I wasn't clear enough. I meant it as an option (ie >> argument to the constructor) on the EntityCollection class. >> >> What would a use case for what you suggest be? If you specify a >> specific resolve_root for *one* particular entity, you might as well >> use the absolute paths. That feature would only make sense if you have >> *lots* of relations to the same target module within the same entity >> *and* that target module is not the current module (or one close to it >> in the module hierarchy). This seems like a very unlikely combination >> and not worth a feature in the default distribution (you could still >> implement it as a custom collection if you wish). > For example, I thought of merging different projects, which have > different module roots. So that you just set the default option > reslove_root different depending whether you are in the former project A > part or in that of project B. Hmmm, that makes some sense, but for that use case, I would rather either use two different collections (using the two different module_root) or use two different base classes with the module_root option set as an option_default on them. That might not be possible at the moment (I'm not really sure), but I'd rather fix that than implement something the wrong way. The reasoning is that module_root really feel like it only makes sense for a group of entities and not for a single entity, and specifying it over and over on each entity seems like dumb to me. > Also think of the problem, that if the resolve_root is defined on > collection basis, you can never "break out" using absolute path. I thought at first that it was a feature, rather than a problem... But on second thoughts, it might be a problem indeed. Let us imagine we are in the following setup: all your project entities are define in a "db" module, but you also use TurboGears (or whatever external library/framework which provides some elixir entities) and its provided "User" entity. Just because of that one entity, you couldn't use the module_root option which would otherwise make a lot of sense. I still don't like the per-entity module_root option, because inside the entity using it (to set the module_root to None), you'd have to use absolute paths (or relative paths) for all the relationships, and not just the one needing to "break out". As a solution to this, it *might* be a good idea to add a mechanism to "force" absolute paths, even when the module_root is not None, for example by using a leading "/", as in "/turbogears.identity.User" (or whatever the real path is). > But you're still right, that those are very special use cases. They can > also be solve using a user-defined resolve function. > Another solution > might be that you allow to provide a function, which generates the > module_root (like the tablename option). That's getting crazy... If it is evaluated on a per-entity basis, it'd make more sense to just provide the option. If not, it doesn't make any sense. > I append a new patch against r455, adding a "module_root" argument to > EntityCollection and making some improvements in the resolve implementation. > General question: where should we discuss this, here or on trac? As a rule of thumb, the "do we implement feature X (with behavior Y and Z)?" should be discussed on the list, while implementation/technical details (how do we implement feature X) and patches should be directed to Trac tickets. -- Gaëtan de Menten http://openhex.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SQLElixir" 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/sqlelixir?hl=en -~----------~----~----~----~------~----~------~--~---
