David, Based on the documentation and the model, you should be able to subclass ERAttachement entity to create a new storageType that can store image data on another table or database. All meta data will remain on the same entity/table. Nothing prevent you to duplicate image meta data on the data storage entity.
If you want to have more than one attachement base entity (split meta data storage with multiple primary keys), I do not see an easy way. The request handler will not be able to figure out the correct meta data entity, it will need to be duplicated anyway, one per meta data storage. Samuel From the package.html file: Custom Storage ERAttachment is written with a modular design. If you want to provide your own storage locations, you can: Add a single-table inheritance ERAttachment subclass with a custom storageType. Add a custom ERAttachmentProcessor subclass that can import into, and provide URLs onto, the storage location. Le 2014-01-13 à 09:43, David Avendasora <webobje...@avendasora.com> a écrit : > Hi all, > > I’m working on a project that needs to have a separate, independent > ERAttachment setup. What I mean is that the project is already using > ERAttachment for a few things, but now I have a need for all of > ERAttachment’s functionality, only storing all the meta-data and even > db-based attachments in a completely different database than where the > existing attachments are stored. > > I have done exactly this before by forking ERAttachment into a new > "DaveAttachment" Framework. All the existing attachments worked using the > stock ERAttachment framework, but the new attachments were managed by > DaveAttachment, but that is long-term code management PITA. > > I’m wondering if it would it be possible enable ERAttachment to use multiple > data-stores by programmatically cloning the ERAttachment EOModel at startup > and creating a new EOModel for each “data-store” with independent Entity > names as configured by properties? > > If you only have one data-store (the current functionality) then ERAttachment > would continue to work as-is, but if you specify multiple data-stores in the > properties, that would trigger the programatic creation and loading of the > additional models? > > Does anyone see anything that I’m missing that would not allow this? > > Thanks! > > Dave > > > ————————————————————————————— > WebObjects - so easy that even Dave Avendasora can do it!™ > ————————————————————————————— > David Avendasora > Senior Software Abuser > Nekesto, Inc. > > > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com > > This email sent to sam...@samkar.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
