not sure which docs you were looking at, but the package.html (which i consider 
to be The Docs (TM) ) looks correct:

public ERTaggable<Person> taggable() {
        return ERTaggable.taggable(this);
}

public static ERTaggableEntity<Person> taggableEntity() {
        return ERTaggableEntity.taggableEntity(Person.ENTITY_NAME);
}

notice it's using the factory method not the constructor.

was this a misread or a docs bug somewhere else?

ms

On Jan 25, 2010, at 6:32 PM, Joe Little wrote:

> Another hitch. Docs say to create a convenience method:
> 
> ERTaggableEntity provides entity-level tag management and fetching
> methods. Typically you would provide a cover method from your entity
> class to an instance of an ERTaggableEntity: public class Person
> extends _Person { ... public static ERTaggableEntity taggableEntity()
> { return new ERTaggableEntity(Person.ENTITY_NAME); } }
> 
> So.. when I define
> 
> public static ERTaggableEntity taggableEntity() {
>               return new ERTaggableEntity(Company.ENTITY_NAME);
>       }
> 
> I get an error since Company.ENTITY_NAME returns a string where as the
> ERTaggableEntity expects an EOEntity in the constructor. However,
> nothing else seems to work there either. Another point where I must be
> doing something wrong.
> 
> 
> 
> 
> On Mon, Jan 25, 2010 at 2:54 PM, Joe Little <jmlit...@gmail.com> wrote:
>> I wanted a to-many relationship for attachments on multiple entities
>> (journals, payments,invoices, whatnot). In the end, I added that one
>> line model dependency and it work. My model defines an entity called
>> FileAttachment, which itself is modeled as a to-many for multiple
>> other entities. FileAttachment has only the to-one relationship to
>> ERAttachment as it seemingly requires based on what's documented. This
>> may add a little work in creating an extra entity before uploads can
>> happen, but it cleanly allows the two-many that I need.
>> 
>> On Mon, Jan 25, 2010 at 1:58 PM, Mike Schrag <msch...@mdimension.com> wrote:
>>> sketchy.
>>> 
>>> In your model, it has a to-one relationship to ERAttachment, right?  it 
>>> should have figured that out automagically and not even required 
>>> ERAttachment declared explicitly, though it's generally a good thing to do 
>>> anyway, since an explicit declaration defines the version #.
>>> 
>>> On Jan 25, 2010, at 4:56 PM, Joe Little wrote:
>>> 
>>>> Never mind my last comment. Yes, I put the below modelDependencies
>>>> value in my primary migration, and it works now.
>>>> 
>>>> On Mon, Jan 25, 2010 at 1:50 PM, Mike Schrag <msch...@mdimension.com> 
>>>> wrote:
>>>>> hmmm ... out of curiosity, in your ERAttachmentMigration subclass, if you
>>>>> add the method:
>>>>> 
>>>>> 
>>>>> 
>>>>>   @Override
>>>>>   public NSArray<ERXModelVersion> modelDependencies() {
>>>>>   return new NSArray<ERXModelVersion>(new ERXModelVersion("ERAttachment",
>>>>> 1));
>>>>>   }
>>>>> 
>>>>> does that fix it? we should probably put that in there.
>>>>> ms
>>>>> On Jan 25, 2010, at 4:34 PM, Joe Little wrote:
>>>>> 
>>>>> I'll do that. Also ran into trouble with ERAttachment. Doesn't it
>>>>> auto-migrate in the table creation?
>>>>> 
>>>>> Failed to execute 'ALTER TABLE FILE_ATTACHMENT ADD CONSTRAINT
>>>>> FILE_ATTACHMENT_ATTACHMENT_ID_id_FK FOREIGN KEY (ATTACHMENT_ID)
>>>>> REFERENCES ERAttachment (id) DEFERRABLE INITIALLY DEFERRED'
>>>>> ERROR: relation "erattachment" does not exist
>>>>> 
>>>>> "If you use Project Wonder migrations and migrateOnStartup, then the
>>>>> ERAttachment tables will be automatically created for you on the first
>>>>> launch. If you do not, then you can either manually execute the
>>>>> .migration SQL scripts that are in the Resources folder (execute them
>>>>> in numeric order), or you can open the EOModel and generate SQL for
>>>>> your particular database."
>>>>> 
>>>>> I definitely have the migrations running as that's how I'm building my
>>>>> DB and adding ERTaggable.
>>>>> 
>>>>> On Mon, Jan 25, 2010 at 1:22 PM, Mike Schrag <msch...@mdimension.com> 
>>>>> wrote:
>>>>> 
>>>>> i honestly don't know why we don't just tell you this outright rather than
>>>>> make you visually diff the two ... seems like something these new-fangled
>>>>> computational machines would be good at. feel free to log a jira on that.
>>>>> 
>>>>> ms
>>>>> 
>>>>> On Jan 25, 2010, at 4:16 PM, Joe Little wrote:
>>>>> 
>>>>> doh.. didn't see that when checking the two.
>>>>> 
>>>>> On Mon, Jan 25, 2010 at 12:54 PM, Mike Schrag <msch...@mdimension.com>
>>>>> wrote:
>>>>> 
>>>>> you can see from the two connection dicts what the diff is ...
>>>>> AffiliateEOModel explicitly declares a plugin name while ERTaggable does
>>>>> not. Just set a global override for plugin and it should fix your problem.
>>>>> 
>>>>> ms
>>>>> 
>>>>> On Jan 25, 2010, at 3:44 PM, Joe Little wrote:
>>>>> 
>>>>> I'm getting this error,
>>>>> 
>>>>> A fatal exception occurred: The connection dictionaries for ERTaggable
>>>>> 
>>>>> and AffiliateEOModel have the same URL and username, but the
>>>>> 
>>>>> connection dictionaries are not equal. Check your connection
>>>>> 
>>>>> dictionaries carefully! This problem is often caused by jdbc2Info not
>>>>> 
>>>>> matching between the two.  One fix for this is to set
>>>>> 
>>>>> ERTaggable.removeJdbc2Info=true and
>>>>> 
>>>>> AffiliateEOModel.removeJdbc2Info=true in your Properties file.
>>>>> 
>>>>> (ERTaggable={password = ""; username = "postgres"; URL =
>>>>> 
>>>>> "jdbc:postgresql://localhost/affiliates"; }; and
>>>>> 
>>>>> AffiliateEOModel={driver = "org.postgresql.Driver"; plugin =
>>>>> 
>>>>> "PostgresqlPlugIn"; password = ""; username = "postgres"; URL =
>>>>> 
>>>>> "jdbc:postgresql://localhost/affiliates"; })
>>>>> 
>>>>> I've also put those two properties in the Properties file without
>>>>> 
>>>>> help. I've defined my database via Properties as well:
>>>>> 
>>>>> dbConnectURLGLOBAL=jdbc:postgresql://localhost/affiliates
>>>>> 
>>>>> dbConnectUserGLOBAL=postgres
>>>>> 
>>>>> dbConnectPasswordGLOBAL=
>>>>> 
>>>>> Has someone seen this before and can suggest what the answer was?
>>>>> 
>>>>> _______________________________________________
>>>>> 
>>>>> 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:
>>>>> 
>>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com
>>>>> 
>>>>> This email sent to msch...@mdimension.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:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to