On Mar 21, 2011, at 6:55 PM, David Avendasora wrote: > 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.
Is fortitude 'merican for masochism? >> 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. Yeah, 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. I don't have any other brillant ideas at the moment. You will also have to deal some of the critical code not working as it relies on _ERAttachment.ENTITY_NAME and will create objects in the "wrong" database. > This way I could have different ERAttachment table sets for distinct, > independent functionality! Doesn't that sound like something everybody would > want? It sounds useful, but cloning the model sounds like a direct path to a bad place. I think you need a Plan B here. Like being able to set where the attachment goes when it is created. I don't know ERAttachment well enough to offer any actually useful advice. Chuck -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
