Re: [ipn-devel] Database

[Jonathan C. <jon...@ya...>]

I think we'll have to use PEERS for the User/Partner object, but we 
still couldn't do queries against it unless we did our own indexing with 
something like Lucene.  But I think we should stick with basic SQL to do 
searching for now.

Feel free to disagree, anyone.

Jonathan

Everson Dave wrote:

> In my mind, the hugest drawback of using the BLOB field is you can't 
> access the contents of the BLOB field unless you use PEERS.  As a 
> result, you can't do SQL queries against the database to get this 
> information.   But this is still a really stick concept.
>
>  
>
> Does anybody have any experience creating a WAR file for a Turbine 
> application and deploying it to a Tomcat 3.2 install?  I tried to 
> deploy a sample application to one to a web servers at one my personal 
> web hosting over the weekend and I can't get the site to appear?  Is 
> there anything special since I am using Tomcat 3.2?   Thought I would 
> check with you guys before going to the Turbine user list.
>
>  
>
> Dave
>
>  
>
>  
>
>  
>
> -----Original Message-----
> From: Jonathan Carlson [mailto:jon...@ya...]
> Sent: Monday, September 10, 2001 9:14 AM
> To: 'ipn...@li... '
> Subject: Re: [ipn-devel] Database
>
> I would vote for this data structure because it is more flexible.  The 
> value type would have to be a  VARCHAR that could be converted into 
> whatever (Integer, Float) if necessary.  I think some DBMS's allocate 
> the maximum space allowed for a VarChar so we'd have to find a happy 
> medium.
>
> While the BLOB idea sounds interesting (and would be very fast), I 
> think it would be more flexible (in terms of searching and setting 
> default values for new properties to have them in a table.  We should 
> build for maintainability and tweak for speed later.  
>
> Although one thing to consider is that we want to keep some privacy 
> for the user management table.  BLOB's would be a little harder to 
> poke around in if anyone gained access to the database.  I vote to 
> stick with the table stuff for now, though.
>
> Given the people that have resonded, it looks like there is a lot of 
> support for MySQL.  Let's go with that.
>
> Jonathan
>
> Everson Dave wrote:
>
>>In the Turbine user object, there is a special BLOB column that is called
>>userData.  I have never seen an implementation like this and I am finding it
>>pretty cool.  It allow us to store name/value pairs without an additional
>>data structure.  I have been playing with this a little bit, but put it off
>>until I completely get the TurbineUser extended for our attributes.
>>
>>If we did create another data structure, I would suggest that we consider
>>something like this:
>>
>>user identifer 
>>parameter type 
>>parameter value 
>>
>>This will allow us to add additional parameters without changing the
>>database structure. This approach is a little bit slower too, but it allows
>>flexable changes.  With good indexes we have been able to make these types
>>of tables perform well. 
>>
>>-----Original Message-----
>>From: Jonathan Carlson
>>Cc: ipn-devel@lists.
>>sourceforge.net <mailto:ipn...@li...>
>>Sent: 9/7/01 3:15 PM
>>Subject: Re: [ipn-devel] Database
>>
>>That's a great suggestion.  
>>
>>I'm big into Xtreme Programming which says "add features only as you 
>>need them", but I don't think this falls into that category.  It's 
>>needed now since we have several different preferences and since there 
>>is no question that more preferences will be added or changed, probably 
>>sooner than later.  It may be a little slower, but I think this is
>>better.
>>
>>Jonathan
>>
>>Lamb, Doug N, /dnl wrote:
>>
>>>I don't see any major problems either.
>>>
>>>However, I do wonder if we should have a separate table user
>>>
>>preferences
>>
>>>like, CountryCode, LanguageCode, KeepPrivate, SubscribedItemRatio and
>>>ItemsPerSession.  It seems likely that user preferences will expand and
>>>
>>we
>>
>>>may want to the database allow for that.
>>>
>>>I am certainly not a Database designer but perhaps the table should be
>>>something like this:
>>>
>>>USER_PREFERENCES
>>>----------------
>>>TYPE (Boolean, String, Integer)
>>>KEY
>>>BOOL_VALUE
>>>STRING_VALUE
>>>INT_VALUE
>>>
>>>Just a thought.
>>>
>>>Doug
>>>
>>>-----Original Message-----
>>>From: Everson Dave [mailto:DAE...@AG...]
>>>Sent: Friday, September 07, 2001 1:05 PM
>>>To: ipn...@li... <mailto:ipn...@li...>
>>>Subject: [ipn-devel] Database
>>>
>>>
>>>Does anybody have any major issues with the database schema that
>>>
>>Jonathan
>>
>>>put together?  I did not see any major show stoppers.  
>>>
>>>I would like to take this database schema and convert it into a XML
>>>
>>file so
>>
>>>that was can use Torque to actually generate the database schema.
>>>Regardless of what OR mapping tool we use, we can use Torque to
>>>
>>actually
>>
>>>construct the database structures. 
>>>
>>>I do have a question, which is probably larger than the database.  It
>>>
>>is the
>>
>>>business logic/thinking behind SubscribedItemRatio.  Does this mean
>>>
>>that the
>>
>>>subscriber can get up to 10 prayer requests from others?  Does this
>>>
>>mean
>>
>>>that the user will see their prayer plus the number of public prayer
>>>requests that they specify in the SubscribedItemRatio?
>>>
>>>Dave
>>>
>>>
>>>
>>>_______________________________________________
>>>ipn-devel mailing list
>>>ipn...@li... <mailto:ipn...@li...>
>>>https://lists.sourceforge.net/lists/listinfo/ipn-devel
>>>
>>>_______________________________________________
>>>ipn-devel mailing list
>>>ipn...@li... <mailto:ipn...@li...>
>>>https://lists.sourceforge.net/lists/listinfo/ipn-devel
>>>
>>
>>
>>
>>_________________________________________________________
>>Do You Yahoo!?
>>Get your free @yahoo.com address at http://mail.yahoo.com
>>
>>
>>_______________________________________________
>>ipn-devel mailing list
>>ipn...@li... <mailto:ipn...@li...>
>>https://lists.sourceforge.net/lists/listinfo/ipn-devel
>>
>