Hi,

I'm a little bit confused. Did no one ever run CE with a PostgreSQL
database? It really seems so unlikely.

Well, I made the following modifications to let it Start-Up and pass
almost all tests. Two tests are failing, but I couldn't figure out
what goes wrong. The same code in irb produces the expected results.


a) as stated in my first post: the values "0" and "1" (within the
fixtures) are not correctly
translated to their boolean Postgresql values. I assume that
ActiveRecord by convention doesn't touch Integer values. Therefore
those values have to be replaced with true/false and ActiveRecord will
take care of substituting the correct values for the underlying
database.

b) the second error from my first post: the following modification to
User.rb / find_by_activity took care of that. What I did was just
returning the user_id for activity. ActiveRecord builds a model from
the data, albeit a non-functional one.
    activities = Activity.since(options[:since]).find(:all,
      :select => 'activities.user_id, count(*) as count',
      :group => 'activities.user_id',
      :conditions => "#{options[:require_avatar] ? ' users.avatar_id
IS NOT NULL' : nil}",
      :order => 'count DESC',
      :joins => "LEFT JOIN users ON users.id = activities.user_id",
      :limit => options[:limit]
      )
    activities.map{|a| find(a.user_id) }

c) in post.rb row 33. A named scope with '1' as a condition became
    named_scope :by_featured_writers, :conditions =>
["users.featured_writer = ?", true], :include => :user

d) Migration 022_create_contests: the two columns 'begin' and 'end'
should/can not be used. According to this:
http://www.postgresql.org/docs/7.3/static/sql-keywords-appendix.html
   are both keywords reserved in SQL99 and SQL92, but only 'end' is
used within PostgreSQL. This means select statements involving a
column named 'begin' will work in PostgreSQL but those statements
containing 'end' will fail.
   Changed the migration to: 'begin_date' and 'end_date'

d1) in Class Contests, replacing of begin/end accordingly

e) Migration 060_still_more_indexes creates an index over two columns,
but drops the index 'taggable_id' defined in migration
045_adding_indexes. Modified remove_index in 060_still_more_indexes to
drop the defined index.
   remove_index :taggings, :column => [:taggable_id, :taggable_type]

f) base_controller.rb / popular_tags: changed group by clause
   sql += " GROUP BY tags.id, tags.name"

g) user.rb / named_scopse: 0/1 instead of true/false
   named_scope :featured, :conditions => ["users.featured_writer = ?",
true]
   named_scope :featured, :conditions => ["users.featured_writer = ?",
true]

h) in comment.rb / previous_commenters_to_notify: the ":group =>
"users.id" seems to be not necessary. Furthermore it generates a
PostgreSQL error.

i) posts_controller.rb / popular: changed group by clause
   WHERE tags.id = taggings.tag_id GROUP BY tags.id, tags.name");

j) tag.rb / related_tags: changed group by clause (twice)
   GROUP BY tags.id, tags.name
   sql += " GROUP BY tags.id, tags.name"

k) contest / validates_presence_of: modified to reflect table changes
 
validates_presence_of :begin_date, :end_date, :title, :banner_title, 
:banner_subtitle

k1) contests_controller_test.rb / test_should_create_contest: begin/
end changed accordingly
  post :create, :contest => {:title => 'created from
tests', :banner_title => 'created from tests', :banner_subtitle =>
'created from tests', :begin_date => 500.days.ago.to_s, :end_date =>
0.days.ago.to_s }

k2) contests_controller_test.rb / test_should_require_title: begin/end
changed accordingly
   post :create, :contest => {:banner_title => 'created from
tests', :banner_subtitle => 'created from tests', :begin_date =>
500.days.ago.to_s, :end_date => 0.days.ago.to_s }

k3) contest_test.rb / test_transform_post: begin/end changed
accordingly
   cat = Contest.new(:begin_date => Time.now, :end_date => Time.now +
30.days, :title => 'test contest', :banner_title => 'test
contest', :banner_subtitle => 'test contest', :raw_post => "<script></
script>")

k4) contests.yml: begin/end changed accordingly
      begin_date: <%= 500.days.ago.to_s :db %>
      end_date: <%= 1.days.ago.to_s :db %>

      bggin_date: <%= 500.days.ago.to_s :db %>
      end_date: <%= (0.days.ago + 4.days).to_s :db %>

k5) views/contests/new.html.erb: begin/end changed accordingly
        <p><%= f.date_select :begin_date %></p>
        <p><%= f.date_select :end_date %></p>

k6) views/contests/edit.html.erb: begin/end changed accordingly
        <p><%= f.date_select :begin_date %></p>
        <p><%= f.date_select :end_date %></p>

k7) contest.rb / start_time && end_time: begin/end changed accordingly
   self.begin_date
   self.end_date

k8) views/contests/show.html.erb: begin/end changed accordingly
   <h3>From <%= @contest.begin_date.strftime("%B %d, %Y") %> To <%=
@contest.end_date.strftime("%B %d, %Y") %></h3>

k9) contest.rb / active?: begin/end changed accordingly
   (self.begin_date < Time.now ) and (self.end_date > Time.now )

l) Migration 010_create_invitations.rb: fk referencing user_id is
defined as string, changed to integer
    t.column "user_id", :integer

m) clippings_controller_test.rb / test_should_create_clipping: tags
returned for clipping are not in the same order as they where
specified at creation. Current test fails since it expects the same
order. Added sort to sort the tags after retrieval
   assert_equal ['tag1', 'tag2'], clipping.tag_list.sort

m1) clippings_controller_test.rb / test_should_update_clipping: same
as m, added sort
    assert_equal ['tagX', 'tagY'], clipping.tag_list.sort

n) post.rb / find_most_commented: group by
   :group => self.columns.map{|column| self.table_name + "." +
column.name}.join(","),

o) Migration 047_add_polls.rb: fk user_id defined as string, changed
to integer
   t.column :user_id, :integer

p) topics.controller_test.rb /
test_sticky_and_locked_protected_from_non_admin: I'm not sure about
this, but it seems, that the object was not correctly referenced to be
found/instantiated during the test. Added forums(..) around the
object.
   assert ! users(:joe).moderator_of?(forums(:rails))

q) users_controller_test.rb / test_should_activate_user: I think
setting the activation code to nil is not the way to go. Instead it
should be a fairly unique string.
   users(:quentin).activation_code = ':quentin_activation_code'

r) post_test.rb / test_update_poll: The test tried to update a poll
created by fixture. I guess, this poll already had some answers (not
empty) since it would get updated. The new poll is now created for a
post which doesn't already have a poll.
   assert posts(:not_funny_post).create_poll({:question => 'Who can
have a great time?'}, ['I can', 'You can', 'No one can'])

    assert posts(:not_funny_post).update_poll({:question => 'Who can
have a terrible time?'}, ['Foo', 'Bar'])

    assert_equal 'Who can have a terrible time?', posts
(:not_funny_post).poll.question
    assert_equal 'Foo', posts
(:not_funny_post).poll.choices.first.description
    assert_equal 'Bar', posts
(:not_funny_post).poll.choices.last.description

s) clipping_test.rb / test_should_get_clipping_image: wrong assertion
data? One clipping is created but the assert_difference expects 4
additional?
    assert_difference Asset, :count, 1 do

On 17 Jan., 12:47, jak4 <[email protected]> wrote:
> Hi,
>
> I just started playing around with CE. Unfortunately there seems to be
> some problems with Postgresql.
>
> First, the values "0" and "1" (within the fixtures) are not correctly
> translated to their boolean Postgresql values. Whatever went wrong
> there, changing those values to "false" and "true" took care of that.
>
> Second and more severe is the error thrown by Postgresql for the
> following statement:
>   SELECT *, count(*) as count FROM "activities"  LEFT JOIN users ON
> users.id = activities.user_id WHERE (activities.created_at >
> '2009-01-10 11:21:33.504753')  GROUP BY activities.user_id ORDER BY
> count DESC LIMIT 5
>
> Postgresql states that: ERROR: column "activities.id" must appear in
> the GROUP BY clause or be used in an aggregate function.
>
> And of course this makes sense, since Postgresql could only guess the
> other values need for the "Select *" part of the query.
>
> Any ideas on how this could be fixed?
>
> Best regards
>   Johannes
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"CommunityEngine" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/communityengine?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to