yeah -- docs bug in ERTaggableEntity ... Sorry about that. They got out of
date. I think it USED to be what was in ERTaggableEntity and then changed.
ms
On Jan 25, 2010, at 6:35 PM, Mike Schrag wrote:
> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
>>>>> 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 <[email protected]>
>>>>>> 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 <[email protected]>
>>>>>> 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 ([email protected])
>>>>>>
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>
>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com
>>>>>>
>>>>>> 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/mschrag%40mdimension.com
>
> 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]
