Ok, so assuming I have a list of all the relationships (I'd probably iterate over all the types and identify properties with ActiveRecord attributes on them and PropertyTypes that are subclasses of ActiveRecordBase).
How would I then programatically generate appropriate queries at runtime for this? what would be most suited to it? you mentioned something about Criteria or HQL? Thanks Josh On Apr 26, 1:22 am, Patrick Steele <[email protected]> wrote: > Comments below... > > --- > Patrick Steelehttp://weblogs.asp.net/psteele > > On Sun, Apr 24, 2011 at 5:30 AM, JoshG <[email protected]> wrote: > >> Why not just write queries (either Criteria or HQL) to get the > >> information you want? > > > This is a possibility though I am trying to find another solution if > > there is one. Because I do not know the types until runtime and the > > types do not know about each other until runtime either, I would have > > to use reflection to search through all the properties on the types > > and generate queries that would find references to each Type of object > > in the entire database.... possible, but not straightforward. Though, > > if you think this is pretty easy - I'd love to know how you would do > > it, I'm looking for the simplest/felxible solution. > > I think you would need to use reflection. That's what ActiveRecord > does to determine how to interact with nHibernate, but since you're > going outside of what ActiveRecord does (auto-determination of > relationships), I think reflection would be the best way (or not -- > see below). > > > To better describe the situation, Imagine I have written an > > application that stores Person records, and their social linkages. But > > I have also added the ability for plugins to the App to specify > > different types of objects - i.e. Pets. > > Now, I want to be able to develop an editor for this DB such that I > > can edit the contents of a Person (easy), but on the side of the > > editor I wish to see a list of all the objects in the DB that > > reference the one I am currently editing (the subject of this > > thread). > > In reality that isn't the application btw > > > Hopefully that is a bit clearer? > > Perhaps your plugin system would support that, as part of registering > a plugin, the relationships could be identified up-front. So you > wouldn't have to use as much reflection, but instead, your plugins > could tell you how they are related to the other parts of your system. > It does place more of the burden on the plug-in developers, but I > think it would simplify your system a bit more. -- You received this message because you are subscribed to the Google Groups "Castle Project Users" 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/castle-project-users?hl=en.
