[Pachy-Dev] installation for mac server

[Joshua Archer]

My guess is that there's a problem with the way the primary key is  
being declared that might be a difference between MySql 4 and MySql  
5. Most of these scripts were developed on MySql 4, so we probably  
need to update them for MySql 5.  Also, I think your encoding might  
be set incorrectly. It should be set to UTF-8, and it appears you  
have it set to Latin1, which could cause a problem with passwords.

On Jul 31, 2007, at 8:45 AM, Meira Josephy wrote:

> Hi Joshua,
>
> pachyderm version:  I downloaded the pachyderm_2_0_4_bin.tar.gz   
> installation from Source Forge.
>
> mysql version:  5.0.41
>
> After trying to import the pachyderm_create_tables.sql script from  
> the command line, the same error message appeared. So its probably  
> not related to the myphpadmin interface.
>
> ERROR 1064 (42000) at line 5: You have an error in your SQL syntax;  
> check the manual that corresponds to your MySQL server version for  
> the right syntax to use near 'DESC text,
>   PRIMARY KEY  (DEFAULT_ID)
> ) TYPE=MyISAM' at line 9
>
> I am attaching the cleaned up version and the tables dump. It would  
> be great if you could let me know if im missing something.
>
> i would very much like to be able to use this product for an online  
> exhibit for an arts organization but im starting to run out of time  
> so any suggestions you might have would be great.
>
> thanks,
>
> Meira
>
> <pachydermpach.sql>
> <pachyderm_create_tables.sql>
>
> On Jul 26, 2007, at 3:10 PM, Joshua Archer wrote:
>
>> Hello Meira,
>>
>> Thanks for the information. A few more questions: did you download  
>> the installation from Source Forge? Which installation package did  
>> you choose? That will help in debugging, and also will help us  
>> correct the problem in future install packages.
>>
>> I've also seen some problems with some versions of the scripts  
>> with myphpadmin - you might try to install the scripts from the  
>> command line mysql client. What version of MySql are you running,  
>> and could you capture and send back the exact error messages  
>> you're seeing with the SQL script? Also, if you could send along  
>> the cleaned-up version, we can use that to update the install  
>> package and make it better (thanks).
>>
>> What's also possible is that you might be missing important data  
>> in the defaults table, or it might be incorrect (set for windows  
>> values instead of OS X values) -- if you can create a dump of your  
>> defaults table and send that along, I can double-check it for  
>> obvious errors.
>>
>> I don't think it's a connection problem with MySql, as you'd get a  
>> JDBC error or some other authentication error that would occur  
>> before you get to the point you describe.
>>
>> Thanks,
>>
>> Joshua
>>
>>
>>
>> On Jul 23, 2007, at 9:24 PM, Meira Josephy wrote:
>>
>>> Dear Joshua,
>>>
>>> Thank you for your elaborate answer.
>>>
>>> Here are some information items: I  have installed pachyderm on  
>>> an iMac (intel) that runs OSX 10.4. I basically followed the  
>>> instructions provided for an OSX installation, although, i did  
>>> run into a problem, when trying to import SQL "script" file drawn  
>>> from a folder designated for OSX into the mysql database. During  
>>> import (using myphpadmin), the table clauses generated an error  
>>> stating that some sub-clause was not valid SQL. For some reason  
>>> when importing SQL "script" file from a folder designated for  
>>> Windows, the import worked fine. in the end I decided to "clean  
>>> up" the SQL script  designated for OSX by comparing it to the one  
>>> for Windows, and selectively changing the commands included in  
>>> the script.
>>>
>>> It is not clear to me why the SQL scripts for OSX generated  
>>> errors during import. However, as far as i can tell, the changes  
>>> i made did not affect the table and field structures. Given your  
>>> description, however, perhaps some change was significant. This  
>>> would lead me back to the question why the import of SQL script  
>>> on OSX  didn't work.
>>>
>>> I am also wondering whether the error could have occurred because  
>>> Pachyderm wasn't able to connect or logon to the MySQL database  
>>> -- although i wouldn't know why  that should happen -- as the  
>>> mysql database is running, and has a database with correct name  
>>> and password, and privileges defined.
>>>
>>> Would it be helpful if i were to export the current tables and  
>>> send them to you ...
>>>
>>>
>>> thank you,
>>>
>>> Meira
>>>
>>>
>>> On Jul 23, 2007, at 7:50 PM, Joshua Archer wrote:
>>>
>>>> Hello Meira,
>>>>
>>>> First I might just take a step back and ask you how you  
>>>> attempted your initial installation, what's the operating  
>>>> system, etc. Before we dig into open heart surgery on your  
>>>> install, perhaps there's an easier thing we can try to make  
>>>> things work.
>>>>
>>>> To elaborate on what I was postulating before, Pachyderm  
>>>> understands all of its potential data sources as external plug- 
>>>> ins, including the native asset repository, contained in  
>>>> AssetDBSupport.framework. This framework has within it  
>>>> subclasses that conform to the API Pachyderm expects for its  
>>>> data sources (defined in the Apollo frameworks), and also has  
>>>> within it a WebObjects model file, which maps java classes /  
>>>> entities to database tables and entries. This efficiency allows  
>>>> WebObjects programmers to never have to write SQL code, as  
>>>> WebObjects knows how to handle all the transactional interaction  
>>>> between the database and the java objects via the model file. If  
>>>> that model file is corrupt or does not match what's in the  
>>>> actual database, it can cause errors, and those errors will  
>>>> surface as exceptions that propagate upwards into the Pachyderm  
>>>> application and cause it to crash. If you are experiencing an  
>>>> exception at the point your log file indicates, it could be  
>>>> because the model file is corrupt or because what is described  
>>>> in the model file doesn't match what's in the actual database.  
>>>> Or, it could be something totally unrelated, unfortunately. In  
>>>> any case, it's when Pachyderm registers the AssetDBSupport  
>>>> framework as a data source that the exception happens, so we can  
>>>> focus in on that chunk of code.
>>>>
>>>> Joshua
>>>>
>>>>
>>>> On Jul 23, 2007, at 3:24 PM, Meira Josephy wrote:
>>>>
>>>>> Hello Joshua,
>>>>>
>>>>> Thanks for your reply. Do you think you could elaborate on what  
>>>>> you mean by making sure the contents are in order and the model  
>>>>> file?
>>>>>
>>>>> Thanks,
>>>>> Meira
>>>>>
>>>>> On Jul 23, 2007, at 3:16 PM, Joshua Archer wrote:
>>>>>
>>>>>> Hello Meira,
>>>>>>
>>>>>> It's possible that the model file for AssetDBSupport is  
>>>>>> damaged or isn't being found, and that's causing  
>>>>>> initialization problems inside the object store class, causing  
>>>>>> the exception. Unfortunately the Apollo libraries out of the  
>>>>>> box don't have error logging to give that sort of detail. I'd  
>>>>>> just check to make sure the contents of AssetDBSupport are all  
>>>>>> in order, and that your mysql database tables match what's in  
>>>>>> the model file.
>>>>>>
>>>>>> Joshua
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>

------------------------------------------------------------------------ 
-----
Joshua Archer
Software Engineer, CSU - Center for Distributed Learning
Phone: 707.664.2085,  Fax: 707.664.4350
------------------------------------------------------------------------ 
-----