On 21 Apr, 2010, at 1:59 , osimons wrote: Hi all,
> On Apr 20, 4:43 pm, Remy Blank <[email protected]> wrote: >> Christian Boos wrote: >>> Not good. But once you know you can call things like `model.exists`, or >>> you can do other useful things with a model object then it will make >>> sense. But maybe you had some other use cases in mind? >> >> I had a lowest common denominator in mind, which indeed does seem to >> consist solely of `.exists`. That... > > There is no such thing - there may be some similarities in the Trac > code based on the model code originally sharing some common patterns, > but I don't have an 'exists' property/method for my FullBlog model for > blog posts (as one example). For Bitten this is different as a > resource in the 'build' realm can be either a configuration or a > specific build number - meaning you can also get completely different > type of model objects back depending on ID. Nothing can or should be > assumed about what it represents. I do agree on this, we also experienced with Agilo for Scrum that it is hard to normalize everything back to one pattern, even if we tried to. We started by adding a kind of "ORM" that is very simple and try to standardize the common operations like load, save, select... initially emulating the Trac model... well that is also a bit of a mess, the way the Milestone behave is not consistent with what the ticket does... this is fine, but is not helping new developers to join the troop and is not helping in building a consistent flow either (e.g: save methods returning True or raising exceptions vs. model id... or silent behavior on insert or update). As for the resources, if the initially meant usage was to have an independent key transporter, in order to be able in certain places - e.g.: permissions - to load a model without knowing how actually the model was looking like, fine... but if that was the purpose they are already far enough. They are not easy to use if someone has a compound key, but that is something that can be overcome using hierarchy. So for me Resource is not an ORM, or if it should become, than is better to look for real ORMs, or anyway to strain for simplicity. >>> The other related use cases I can think of are the >>> IResourceChangeListener (discussed in >>> http://trac.edgewall.org/ticket/8834) >> >> ... and the IResourceChangeListener, yes. >> >>> In this situation what's problematic is not >>> so much the possibility to create a model from a resource in a generic >>> way, but the fact that this creation has to be *repeated* over and over >>> again. >> >> Exactly, it would be a convenience functionality, and an optimization in >> the case of IResourceChangeListener, as every listener would get the >> same Resource object (with the same model object associated). >> >>> a) and b) together might fit >>> the bill: when accessing resource.model the first time, a call to >>> `resource_get_model` could be made, binding the model to the resource. >> >> I'm not too keen on caching, actually. Model objects are mutable (e.g. >> the version of a WikiPage increases when saving), so this would be >> tricky to get right. However, if we attach the model object to the >> resource on first lookup, without any caching, we should already have >> all the convenience we need. >> >>> Not to mention that if we would store the resource >>> manager itself instead of the env, we would avoid a component lookup >>> each time one of these helper is called... >> >> This sounds like a good plan, yes. > > The major selling point for 'resources' as a concept was that we > needed lots of them when dealing with the new security system for > 0.11, and generally needed a cheap way to create and mutate something > to identify a Trac resource without instantiating them. We create > resources all over the place, mutate and shape them as we need for the > use-cases we need - not to mention the big unknown quantity of plugins > using, reusing or mutating resources as they fly by. Right, sorry I didn't read this :-P > So, we have ended up with lots of code that create resources. We have > a lot of code that create half-baked resources that we mutate. If > these resources also could contain references to model objects of > unknown state and origin, that would in my opinion be a recipe for > disaster - certainly when developers started to use that as an entry > point to the model objects, and the resource and model somehow > persisted or was cached. I also agree on the fact that this code is may be too much, it is not well documented, and therefore people are doing whatsoever with that... > The 'convenience' we have generally used so far has in fact been the > other way around as we have attached a Resource object to the Model in > order to have it at hand. That then causes intermingled and possibly > circular references. Each added layer, and each feature added to each > layer, increases the complexity. We'd get all kinds of hard-to-debug > errors that sporadically arise due to some strange combination of > circumstances. Never happen to us, but I see your point... > "Explicit is better than implicit" as the zen says, and I cringe each > time I offer support on IRC pointing people to > formatter.context.resource as location of this very important > information in macro code. Let 10 able coders stare at the Trac code > and see if any of them come up with formatter.context.resource.model > as the obvious starting point to access properties they need... If > something is important and needed, then pass it explicity. Complex > objects that reference other known and unknown objects in ways that > are hard to detect, literally caused me months of sleepless nights > while trying to figure out the rare circumstance why my site went down > at irratic intervals: > http://trac-hacks.org/changeset/4366 Nice one :-) > The only way these new suggestions makes sense is if the resource (and > user of the resource) could make some general assumptions about the > underlying model. Which I suppose is GenericTrac again... Personally > I'm not in favour of this, and enjoy the flexibility currently > enjoyed. As one example against the #8834 ticket (generic resource > change listening/notification), my FullBlog needs to notify when > comments are added. Comments are not resources, and they do not create > a new version of the blog post itself which is separately editable for > new versions. Still, for notifications, comments are just as important > as the resource itself. Shoe-horning all features into common model-, > manipulator- and listener infrastructure is contrary to the general > "feel" of the code base that has made Trac successful and enabled the > great variety of plugins that we actually have. I agree, not necessarily everything needs to behave the same way, and not necessarily everything needs to be versioned, I am for a more explicit approach too, as it is easier to understand for people willing to contribute and it is probably easier in general to maintain as it is not on a Meta level :-) I would like to have a more specific DB API, that would allow contributors to use a common way to generate new tables, and use some common infrastructure to manage data and models associated to it. As of now every plugin is mostly doing things in his/her own way... so we have a very scattered approach to data, that makes compatibility and coexistence between plugins very difficult to achieve. > I know, at one stage I actually championed accessing model through > resource, but that was in the name of "security" and not > "convenience". My idea was that the resource system could be the > gateway to accessing data in a new abstracted "business layer" that > worked regardless of entry point (commandline, request, ++) and where > security was included for free - the developer need not be concerned > with security directly as that would be gated through the resource > system. Well here I am not sure I understands you, but I see this in contrast with what you expressed before in terms of simplicity. If you want the Resources to be a kind of high level layer on the model, than how do you plan to transport behavior on the resource? And if you don't, what would be the advantage of having Resources to access the model, if to operate you need to know how the model is designed - and still every model can be different from any other? > We won't be getting there (it has been a few years since we discussed > this), and now I have a strong preference for simple and explicit. > Accessing or inferring anything about models through resources is -1 > from me. +1 to your -1 so is a -2 :-) > :::simon ANdreaT -- You received this message because you are subscribed to the Google Groups "Trac Development" 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/trac-dev?hl=en.
