I think you could do crossmodel subclass. But I never tested it, I'm unsure if works
Amedeo On 22/mar/2011, at 04.25, Chuck Hill wrote: > 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 > > > > > > > > _______________________________________________ > 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/amedeomailing%40insigno.it > > This email sent to [email protected] _______________________________________________ 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]
