On Mar 21, 2011, at 5:09 PM, Chuck Hill wrote: > > On Mar 19, 2011, at 4:32 AM, David Avendasora wrote: > >> Hi all, >> >> We are currently using ERAttachment in one of our projects. The particular >> app it is being used in has it's own DB which resides on a physically >> separate server from most of the rest of our Schemas. This app works great, >> and handles literally thousands of attachments per day (hence the reason for >> it's own physical server and database). >> >> Now I want to use ERAttachment for another purpose. I want to put it in a >> framework that could be used by many, if not all, of our applications, >> including the system that currently uses ERAttachment. I can't use the >> existing ERAttachment tables in this other, physically-seperate database >> because EOF can't do the cross-database fetches it needs to. >> >> Theoretically, I could have the DBAs setup a cross-database link between the >> two databases so EOF could get to the other Schema, but it wouldn't really >> make sense from an organizational perspective to have just the attachments >> on a different server, that is for a completely different business purpose, >> from all the rest of the new framework's tables. >> >> The problem is that ERAttachment seems to only allow you to configure one >> connection dictionary for it. It doesn't appear that you can make use of the >> "configurationName" functionality to have different sets of ERAttachment >> tables. >> >> Am I missing how that can be implemented, or is it something that I >> shouldn't even be attempting? It seems quite limiting to only allow one set >> of ERAttachment tables per application. > > Not really sure what you are trying to do. :-)
Most people find that to be the case most of the time. I admire your fortitude to repeatedly wade into my ramblings. > You want to use a model twice in the same app but pointing to different > tables? Well, yeah. But when you say it like that it sounds kinda dirty, or something. > If you use different tables, then you need different entity names or you need > the models to be in a different EOModel group, no? Well, I guess I could just programmatically create a copy of the ERAttachment model at launch with a new name based on a property that would need to be set in any project that has ERAttachment.framework on it's classpath. During the creation of this new EOModel, I could rename the existing entities by prefixing the names just like I would do for the EOModel itself. This way I could have different ERAttachment table sets for distinct, independent functionality! Doesn't that sound like something everybody would want? Dave _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
