expected behavior ... cleanup=true on ERAttachmentUpload to delete the previous 
attachment.

On Feb 17, 2010, at 5:51 PM, Johnny Miller wrote:

> LOL.
> 
> Next question,
> 
> When I first upload the file using the ERAttachmentUpload component the 
> result is what I'd expect it to be i.e. an object of my entity and an object 
> of erattachment are created and the file is stored per the configuration.
> 
> However, if I then update my entity and upload a new file I get a behavior I 
> didn't expect.  This time a new entity of type ERAttachment is created and 
> the old one is now left dangling in the database without any reference to it. 
>  The file(s) on the system are also untouched.
> 
> Does this mean I have a problem in the model or is that the expected behavior 
> and I need to add some logic to complete the clean up?
> 
> Thanks,
> 
> Johnny
> 
> 
> On Feb 16, 2010, at 1:23 PM, Mike Schrag wrote:
> 
>> i would assume that "later" is an unbounded value. i'm not actively working 
>> on it ... 
>> 
>> On Feb 16, 2010, at 6:11 PM, Johnny Miller wrote:
>> 
>>> Sorry, hit the reply instead of reply all...
>>> 
>>> OK, so if you want the thumbnailing functionality you need to layer it on 
>>> yourself.  In the docs it states "Later versions will support generating 
>>> thumbnails in addition to the original image."
>>> 
>>> Is this in the "works" or should I just assume that it's low in the 
>>> priority stack and go with my own solution?
>>> 
>>> Best,
>>> 
>>> Johnny
>>> 
>>> 
>>> On Feb 16, 2010, at 12:41 PM, Mike Schrag wrote:
>>> 
>>>> keep questions on the list, please
>>>> 
>>>> if you set the scale factor on the attachment upload, it will scale it 
>>>> permanently. if you set the scale on the viewer, it will just do html 
>>>> scaling (and send the full sized version) -- it does _not_ thumbnail it on 
>>>> the fly.
>>>> 
>>>> ms
>>>> 
>>>> On Feb 16, 2010, at 5:13 PM, Johnny Miller wrote:
>>>> 
>>>>> OK, it's sinking in slowly :p
>>>>> 
>>>>> I think everything is set up on the database and model side correctly.
>>>>> 
>>>>> Sorry to inundate you with questions but...
>>>>> 
>>>>> An overview question.  Once the original is stored can I use 
>>>>> ERAttachmentViewer to create scaled versions of the original?  If it is 
>>>>> scaling does it create a permanent copy of the scaled version?  Or does 
>>>>> it create a new scaled image every time it is requested?
>>>>> 
>>>>> Thanks again,
>>>>> 
>>>>> Johnny
>>>>> 
>>>>> 
>>>>> 
>>>>> On Feb 16, 2010, at 11:46 AM, Mike Schrag wrote:
>>>>> 
>>>>>> the only thing ERAttachment needs is the original two tables (primary 
>>>>>> one and the one for blob data). on your side, you would need the foreign 
>>>>>> key id ...  you can extend ERAttachmentMigration to do that.
>>>>>> 
>>>>>> ms
>>>>>> 
>>>>>> On Feb 16, 2010, at 4:35 PM, Johnny Miller wrote:
>>>>>> 
>>>>>>> WOW.  That's really a new paradigm from the way I've been doing things.
>>>>>>> 
>>>>>>> So, to get started I'm going to keep things simple and just use the 
>>>>>>> to-one attachment.
>>>>>>> 
>>>>>>> I'm also using the file system storage type with the web server 
>>>>>>> directly serving the files.
>>>>>>> 
>>>>>>> In that set up will anything be created in the database when I migrate 
>>>>>>> on start up?  Right now, I'm not seeing anything besides the _dbupdater 
>>>>>>> table.
>>>>>>> 
>>>>>>> Thanks again,
>>>>>>> 
>>>>>>> Johnny
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Feb 16, 2010, at 11:22 AM, Mike Schrag wrote:
>>>>>>> 
>>>>>>>> whether you choose a to-one or a many-to-many depends on whether you 
>>>>>>>> want one attachment or many ... if you have company.logo it's a to-one 
>>>>>>>> to attachment, with no inverse relationship. if it's gallery.photos 
>>>>>>>> then it's a many-to-many with no inverse relationship from attachment.
>>>>>>>> 
>>>>>>>> On Feb 16, 2010, at 4:13 PM, Johnny Miller wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> I've been using ERAttachment's image processor but on a new project 
>>>>>>>>> I'm going to try out using the entire framework i.e. all the 
>>>>>>>>> automagic file handling wonderment.
>>>>>>>>> 
>>>>>>>>> A question on modeling the attachments.
>>>>>>>>> 
>>>>>>>>> When you create the relationship between the entities' key and 
>>>>>>>>> ERAttachment is that an optional one-to-one relationship or is it an 
>>>>>>>>> optional one-to-many from your model to erattachment?
>>>>>>>>> 
>>>>>>>>> Thanks in advance,
>>>>>>>>> 
>>>>>>>>> Johnny
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Johnny Miller
>>>>>>>>> Kahalawai Media Corp
>>>>>>>>> http://www.kahalawai.com
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> 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/mschrag%40mdimension.com
>>>>>>>>> 
>>>>>>>>> This email sent to [email protected]
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> Johnny Miller
>>>>>>> Kahalawai Media Corp
>>>>>>> http://www.kahalawai.com
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> Johnny Miller
>>>>> Kahalawai Media Corp
>>>>> http://www.kahalawai.com
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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/jlmiller%40kahalawai.com
>>>> 
>>>> This email sent to [email protected]
>>> 
>>> Johnny Miller
>>> Kahalawai Media Corp
>>> http://www.kahalawai.com
>>> 
>>> 
>>> 
>> 
> 
> Johnny Miller
> Kahalawai Media Corp
> http://www.kahalawai.com
> 
> 
> 

 _______________________________________________
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]

Reply via email to