Closed btbonval closed 11 years ago
jywarren
commented
11 years ago Super, i'm going to try pulling this in manually locally. I've been struggling with auto-sequenced test data in factory_girl, #89, but am just half-assing it for the time being to get the tests to run. Half-assed tests still test things, even if they are ugly, and i'm eager to try the like button stuff.
jywarren
commented
11 years ago Works great! We should write a test or two and push to the production server. Awesome, very exciting!
Can we just query "cached_likes" on any node to see the latest count? Maybe we should make a node.likes alias.
Very eager to start on subscriptions too now... thanks so much Bryan for getting this going!
btbonval
commented
11 years ago Yeah, cached_likes is an attribute of DrupalNode so it may be accessed for any node. The default cached_likes is 0, so new pages are squared away and old pages are properly set upon migration.
You could alias the attribute in DrupalNode with a def, sure.
I will have to learn how testing works now ;) -Bryan On Apr 10, 2013 11:02 AM, "Jeffrey Warren" notifications@github.com wrote:
Works great! We should write a test or two and push to the production server. Awesome, very exciting!
Can we just query "cached_likes" on any node to see the latest count? Maybe we should make a node.likes alias.
Very eager to start on subscriptions too now... thanks so much Bryan for getting this going!
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16179846 .
btbonval
commented
11 years ago Oh, maybe I didn't quite answer the question about cached_likes for getting the most recent count. The Like controller updates the Node's cached_likes in the same transaction as the update to NodeSelection (which stores whether the user likes the page or not).
If the modification to cached_like fails, then NodeSelection will not be updated. If the modification to NodeSelection fails, then cached_like will not be updated.
cached_likes should always represent the current state of how many users like a given node. We could, every so often, run a report with count() to confirm cached_likes is still accurate.
If a user was deleted and that did not cascade through to UserSelection, we'd have phantom users liking nodes. Since the relational database doesn't implement foreign keys, I think this is possible. ActiveRecord might handle it appropriately, though. -Bryan
On Wed, Apr 10, 2013 at 12:11 PM, Bryan btbonval@gmail.com wrote:
Yeah, cached_likes is an attribute of DrupalNode so it may be accessed for any node. The default cached_likes is 0, so new pages are squared away and old pages are properly set upon migration.
You could alias the attribute in DrupalNode with a def, sure.
I will have to learn how testing works now ;) -Bryan On Apr 10, 2013 11:02 AM, "Jeffrey Warren" notifications@github.com wrote:
Works great! We should write a test or two and push to the production server. Awesome, very exciting!
Can we just query "cached_likes" on any node to see the latest count? Maybe we should make a node.likes alias.
Very eager to start on subscriptions too now... thanks so much Bryan for getting this going!
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16179846 .
jywarren
commented
11 years ago You can say :dependent => destroy to kill the likes along with the user, no?
Cool. On Apr 10, 2013 11:10 AM, "Bryan Bonvallet" notifications@github.com wrote:
Oh, maybe I didn't quite answer the question about cached_likes for getting the most recent count. The Like controller updates the Node's cached_likes in the same transaction as the update to NodeSelection (which stores whether the user likes the page or not).
If the modification to cached_like fails, then NodeSelection will not be updated. If the modification to NodeSelection fails, then cached_like will not be updated.
cached_likes should always represent the current state of how many users like a given node. We could, every so often, run a report with count() to confirm cached_likes is still accurate.
If a user was deleted and that did not cascade through to UserSelection, we'd have phantom users liking nodes. Since the relational database doesn't implement foreign keys, I think this is possible. ActiveRecord might handle it appropriately, though. -Bryan
On Wed, Apr 10, 2013 at 12:11 PM, Bryan btbonval@gmail.com wrote:
Yeah, cached_likes is an attribute of DrupalNode so it may be accessed for any node. The default cached_likes is 0, so new pages are squared away and old pages are properly set upon migration.
You could alias the attribute in DrupalNode with a def, sure.
I will have to learn how testing works now ;) -Bryan On Apr 10, 2013 11:02 AM, "Jeffrey Warren" notifications@github.com wrote:
Works great! We should write a test or two and push to the production server. Awesome, very exciting!
Can we just query "cached_likes" on any node to see the latest count? Maybe we should make a node.likes alias.
Very eager to start on subscriptions too now... thanks so much Bryan for getting this going!
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16179846> .
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16187965 .
jywarren
commented
11 years ago whoops, found one small bug which tripped an error in production on the live server, but not in development. Probably because production preloads more stuff and tripped it up front...
belongs_to :other, :class_name = :User, :foreign_key => 'other_id'should have been
belongs_to :other, :class_name => :User, :foreign_key => 'other_id'on line 5 of user_selection.rb
just noting it here, my fix is in the next commit. All else seems perfect and now running on publiclab.org!
btbonval
commented
11 years ago Good find. I have no doubt I would make a mistake like that. The "rocket" is a strange symbol to be forced to type all the time; it harkens back to the day where := (set) was different from = (equals).
Sorry I haven't built tests for Likes yet. I have negotiated contract work with a company which semi-officially began on Monday. Once I have Rails testing down, I should be in a good position to tackle the next task for the website much more quickly.
On Thu, Apr 11, 2013 at 10:47 AM, Jeffrey Warren notifications@github.comwrote:
whoops, found one small bug which tripped an error in production on the live server, but not in development. Probably because production preloads more stuff and tripped it up front...
belongs_to :other, :class_name = :User, :foreign_key => 'other_id'
should have been
belongs_to :other, :class_name => :User, :foreign_key => 'other_id'
on line 5 of user_selection.rb
just noting it here, my fix is in the next commit. All else seems perfect and now running on publiclab.org!
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16239122 .
jywarren
commented
11 years ago No problem at all! Just wanted to update on my integration. Also - i'm not sure how to keep this working -- there are certain indices in the /db/schema.rb file which cause the test migrations to fail and thus the tests to error out. I had commented them out but think i messed it up and deleted them in the merge... totally my fault, but just be aware that the current version of schema.rb has some commented out index definitions which are required for tests to run.
On Thu, Apr 11, 2013 at 10:50 AM, Bryan Bonvallet notifications@github.comwrote:
Good find. I have no doubt I would make a mistake like that. The "rocket" is a strange symbol to be forced to type all the time; it harkens back to the day where := (set) was different from = (equals).
Sorry I haven't built tests for Likes yet. I have negotiated contract work with a company which semi-officially began on Monday. Once I have Rails testing down, I should be in a good position to tackle the next task for the website much more quickly.
On Thu, Apr 11, 2013 at 10:47 AM, Jeffrey Warren notifications@github.comwrote:
whoops, found one small bug which tripped an error in production on the live server, but not in development. Probably because production preloads more stuff and tripped it up front...
belongs_to :other, :class_name = :User, :foreign_key => 'other_id'
should have been
belongs_to :other, :class_name => :User, :foreign_key => 'other_id'
on line 5 of user_selection.rb
just noting it here, my fix is in the next commit. All else seems perfect and now running on publiclab.org!
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16239122> .
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16246999 .
btbonval
commented
11 years ago What does schema.rb do? It seems to be a reflection of the current database schema, but that's all in the database. I'm surprised commenting things out in that file make a difference for testing. If that file only reflects the database, the migrations should be able to reconstruct that anyway, and we don't even need to track it. If schema.rb does something more integral to Rails, we should probably figure out what it does and why it's causing test problems.
On Thu, Apr 11, 2013 at 3:40 PM, Jeffrey Warren notifications@github.comwrote:
No problem at all! Just wanted to update on my integration. Also - i'm not sure how to keep this working -- there are certain indices in the /db/schema.rb file which cause the test migrations to fail and thus the tests to error out. I had commented them out but think i messed it up and deleted them in the merge... totally my fault, but just be aware that the current version of schema.rb has some commented out index definitions which are required for tests to run.
On Thu, Apr 11, 2013 at 10:50 AM, Bryan Bonvallet notifications@github.comwrote:
Good find. I have no doubt I would make a mistake like that. The "rocket" is a strange symbol to be forced to type all the time; it harkens back to the day where := (set) was different from = (equals).
Sorry I haven't built tests for Likes yet. I have negotiated contract work with a company which semi-officially began on Monday. Once I have Rails testing down, I should be in a good position to tackle the next task for the website much more quickly.
On Thu, Apr 11, 2013 at 10:47 AM, Jeffrey Warren notifications@github.comwrote:
whoops, found one small bug which tripped an error in production on the live server, but not in development. Probably because production preloads more stuff and tripped it up front...
belongs_to :other, :class_name = :User, :foreign_key => 'other_id'
should have been
belongs_to :other, :class_name => :User, :foreign_key => 'other_id'
on line 5 of user_selection.rb
just noting it here, my fix is in the next commit. All else seems perfect and now running on publiclab.org!
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16239122> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16246999> .
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16256536 .
jywarren
commented
11 years ago agreed re: more research. My understanding has always been that it reflects Rails' current understanding/awareness of the database, and that it is typically generated upon running rake db:migrate. In our hijacking a Drupal database, it seems that this assumption may not exactly hold.
On Thu, Apr 11, 2013 at 1:49 PM, Bryan Bonvallet notifications@github.comwrote:
What does schema.rb do? It seems to be a reflection of the current database schema, but that's all in the database. I'm surprised commenting things out in that file make a difference for testing. If that file only reflects the database, the migrations should be able to reconstruct that anyway, and we don't even need to track it. If schema.rb does something more integral to Rails, we should probably figure out what it does and why it's causing test problems.
On Thu, Apr 11, 2013 at 3:40 PM, Jeffrey Warren notifications@github.comwrote:
No problem at all! Just wanted to update on my integration. Also - i'm not sure how to keep this working -- there are certain indices in the /db/schema.rb file which cause the test migrations to fail and thus the tests to error out. I had commented them out but think i messed it up and deleted them in the merge... totally my fault, but just be aware that the current version of schema.rb has some commented out index definitions which are required for tests to run.
On Thu, Apr 11, 2013 at 10:50 AM, Bryan Bonvallet notifications@github.comwrote:
Good find. I have no doubt I would make a mistake like that. The "rocket" is a strange symbol to be forced to type all the time; it harkens back to the day where := (set) was different from = (equals).
Sorry I haven't built tests for Likes yet. I have negotiated contract work with a company which semi-officially began on Monday. Once I have Rails testing down, I should be in a good position to tackle the next task for the website much more quickly.
On Thu, Apr 11, 2013 at 10:47 AM, Jeffrey Warren notifications@github.comwrote:
whoops, found one small bug which tripped an error in production on the live server, but not in development. Probably because production preloads more stuff and tripped it up front...
belongs_to :other, :class_name = :User, :foreign_key => 'other_id'
should have been
belongs_to :other, :class_name => :User, :foreign_key => 'other_id'
on line 5 of user_selection.rb
just noting it here, my fix is in the next commit. All else seems perfect and now running on publiclab.org!
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16239122> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16246999> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16256536> .
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16257027 .
jywarren
commented
11 years ago Super; I added a "likes page" for each user: http://publiclab.org/profile/warren/likes On Apr 11, 2013 5:04 PM, "Jeffrey Warren" jeff@unterbahn.com wrote:
agreed re: more research. My understanding has always been that it reflects Rails' current understanding/awareness of the database, and that it is typically generated upon running rake db:migrate. In our hijacking a Drupal database, it seems that this assumption may not exactly hold.
On Thu, Apr 11, 2013 at 1:49 PM, Bryan Bonvallet <notifications@github.com
wrote:
What does schema.rb do? It seems to be a reflection of the current database schema, but that's all in the database. I'm surprised commenting things out in that file make a difference for testing. If that file only reflects the database, the migrations should be able to reconstruct that anyway, and we don't even need to track it. If schema.rb does something more integral to Rails, we should probably figure out what it does and why it's causing test problems.
On Thu, Apr 11, 2013 at 3:40 PM, Jeffrey Warren notifications@github.comwrote:
No problem at all! Just wanted to update on my integration. Also - i'm not sure how to keep this working -- there are certain indices in the /db/schema.rb file which cause the test migrations to fail and thus the tests to error out. I had commented them out but think i messed it up and deleted them in the merge... totally my fault, but just be aware that the current version of schema.rb has some commented out index definitions which are required for tests to run.
On Thu, Apr 11, 2013 at 10:50 AM, Bryan Bonvallet notifications@github.comwrote:
Good find. I have no doubt I would make a mistake like that. The "rocket" is a strange symbol to be forced to type all the time; it harkens back to the day where := (set) was different from = (equals).
Sorry I haven't built tests for Likes yet. I have negotiated contract work with a company which semi-officially began on Monday. Once I have Rails testing down, I should be in a good position to tackle the next task for the website much more quickly.
On Thu, Apr 11, 2013 at 10:47 AM, Jeffrey Warren notifications@github.comwrote:
whoops, found one small bug which tripped an error in production on the live server, but not in development. Probably because production preloads more stuff and tripped it up front...
belongs_to :other, :class_name = :User, :foreign_key => 'other_id'
should have been
belongs_to :other, :class_name => :User, :foreign_key => 'other_id'
on line 5 of user_selection.rb
just noting it here, my fix is in the next commit. All else seems perfect and now running on publiclab.org!
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16239122> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16246999> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16256536> .
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16257027 .
btbonval
commented
11 years ago I thought about something like that myself, but it was from a purely functional standpoint of showing a user his or her own likes. What you made is much prettier than what I would have come up with and makes it easy to share your likes with others.
I just noticed something: the little summary bar with the by-line, date, comment count, and like count. I think I might try modifying that so the like indicator can be used to like/unlike directly from the summary views.
On Sun, Apr 14, 2013 at 12:16 AM, Jeffrey Warren notifications@github.comwrote:
Super; I added a "likes page" for each user: http://publiclab.org/profile/warren/likes On Apr 11, 2013 5:04 PM, "Jeffrey Warren" jeff@unterbahn.com wrote:
agreed re: more research. My understanding has always been that it reflects Rails' current understanding/awareness of the database, and that it is typically generated upon running rake db:migrate. In our hijacking a Drupal database, it seems that this assumption may not exactly hold.
On Thu, Apr 11, 2013 at 1:49 PM, Bryan Bonvallet < notifications@github.com
wrote:
What does schema.rb do? It seems to be a reflection of the current database schema, but that's all in the database. I'm surprised commenting things out in that file make a difference for testing. If that file only reflects the database, the migrations should be able to reconstruct that anyway, and we don't even need to track it. If schema.rb does something more integral to Rails, we should probably figure out what it does and why it's causing test problems.
On Thu, Apr 11, 2013 at 3:40 PM, Jeffrey Warren < notifications@github.com>wrote:
No problem at all! Just wanted to update on my integration. Also - i'm not sure how to keep this working -- there are certain indices in the /db/schema.rb file which cause the test migrations to fail and thus the tests to error out. I had commented them out but think i messed it up and deleted them in the merge... totally my fault, but just be aware that the current version of schema.rb has some commented out index definitions which are required for tests to run.
On Thu, Apr 11, 2013 at 10:50 AM, Bryan Bonvallet notifications@github.comwrote:
Good find. I have no doubt I would make a mistake like that. The "rocket" is a strange symbol to be forced to type all the time; it harkens back to the day where := (set) was different from = (equals).
Sorry I haven't built tests for Likes yet. I have negotiated contract work with a company which semi-officially began on Monday. Once I have Rails testing down, I should be in a good position to tackle the next task for the website much more quickly.
On Thu, Apr 11, 2013 at 10:47 AM, Jeffrey Warren notifications@github.comwrote:
whoops, found one small bug which tripped an error in production on the live server, but not in development. Probably because production preloads more stuff and tripped it up front...
belongs_to :other, :class_name = :User, :foreign_key => 'other_id'
should have been
belongs_to :other, :class_name => :User, :foreign_key => 'other_id'
on line 5 of user_selection.rb
just noting it here, my fix is in the next commit. All else seems perfect and now running on publiclab.org!
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16239122> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16246999> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16256536> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16257027> .
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16345720 .
btbonval
commented
11 years ago I can't get the tests to run, by the way. It looks like we were talking about that in this thread. There is an error with spatial adapter not supporting sqlite, and it looks like nothing else is tried so far as I can tell.
I pulled from the repo and tested about the time you sent your previous
email. Is rake test not the right way to run the tests?
On Sun, Apr 14, 2013 at 1:13 AM, Bryan btbonval@gmail.com wrote:
I thought about something like that myself, but it was from a purely functional standpoint of showing a user his or her own likes. What you made is much prettier than what I would have come up with and makes it easy to share your likes with others.
I just noticed something: the little summary bar with the by-line, date, comment count, and like count. I think I might try modifying that so the like indicator can be used to like/unlike directly from the summary views.
On Sun, Apr 14, 2013 at 12:16 AM, Jeffrey Warren <notifications@github.com
wrote:
Super; I added a "likes page" for each user: http://publiclab.org/profile/warren/likes On Apr 11, 2013 5:04 PM, "Jeffrey Warren" jeff@unterbahn.com wrote:
agreed re: more research. My understanding has always been that it reflects Rails' current understanding/awareness of the database, and that it is typically generated upon running rake db:migrate. In our hijacking a Drupal database, it seems that this assumption may not exactly hold.
On Thu, Apr 11, 2013 at 1:49 PM, Bryan Bonvallet < notifications@github.com
wrote:
What does schema.rb do? It seems to be a reflection of the current database schema, but that's all in the database. I'm surprised commenting things out in that file make a difference for testing. If that file only reflects the database, the migrations should be able to reconstruct that anyway, and we don't even need to track it. If schema.rb does something more integral to Rails, we should probably figure out what it does and why it's causing test problems.
On Thu, Apr 11, 2013 at 3:40 PM, Jeffrey Warren < notifications@github.com>wrote:
No problem at all! Just wanted to update on my integration. Also - i'm not sure how to keep this working -- there are certain indices in the /db/schema.rb file which cause the test migrations to fail and thus the tests to error out. I had commented them out but think i messed it up and deleted them in the merge... totally my fault, but just be aware that the current version of schema.rb has some commented out index definitions which are required for tests to run.
On Thu, Apr 11, 2013 at 10:50 AM, Bryan Bonvallet notifications@github.comwrote:
Good find. I have no doubt I would make a mistake like that. The "rocket" is a strange symbol to be forced to type all the time; it harkens back to the day where := (set) was different from = (equals).
Sorry I haven't built tests for Likes yet. I have negotiated contract work with a company which semi-officially began on Monday. Once I have Rails testing down, I should be in a good position to tackle the next task for the website much more quickly.
On Thu, Apr 11, 2013 at 10:47 AM, Jeffrey Warren notifications@github.comwrote:
whoops, found one small bug which tripped an error in production on the live server, but not in development. Probably because production preloads more stuff and tripped it up front...
belongs_to :other, :class_name = :User, :foreign_key => 'other_id'
should have been
belongs_to :other, :class_name => :User, :foreign_key => 'other_id'
on line 5 of user_selection.rb
just noting it here, my fix is in the next commit. All else seems perfect and now running on publiclab.org!
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16239122> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16246999> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16256536> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16257027> .
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16345720 .
jywarren
commented
11 years ago cool. i'm trying to figure out design-wise how to show a list of who likes a given node. Maybe in a popover or something... have to exercise my UI brain-muscles
On Sun, Apr 14, 2013 at 1:13 AM, Bryan Bonvallet notifications@github.comwrote:
I thought about something like that myself, but it was from a purely functional standpoint of showing a user his or her own likes. What you made is much prettier than what I would have come up with and makes it easy to share your likes with others.
I just noticed something: the little summary bar with the by-line, date, comment count, and like count. I think I might try modifying that so the like indicator can be used to like/unlike directly from the summary views.
On Sun, Apr 14, 2013 at 12:16 AM, Jeffrey Warren notifications@github.comwrote:
Super; I added a "likes page" for each user: http://publiclab.org/profile/warren/likes On Apr 11, 2013 5:04 PM, "Jeffrey Warren" jeff@unterbahn.com wrote:
agreed re: more research. My understanding has always been that it reflects Rails' current understanding/awareness of the database, and that it is typically generated upon running rake db:migrate. In our hijacking a Drupal database, it seems that this assumption may not exactly hold.
On Thu, Apr 11, 2013 at 1:49 PM, Bryan Bonvallet < notifications@github.com
wrote:
What does schema.rb do? It seems to be a reflection of the current database schema, but that's all in the database. I'm surprised commenting things out in that file make a difference for testing. If that file only reflects the database, the migrations should be able to reconstruct that anyway, and we don't even need to track it. If schema.rb does something more integral to Rails, we should probably figure out what it does and why it's causing test problems.
On Thu, Apr 11, 2013 at 3:40 PM, Jeffrey Warren < notifications@github.com>wrote:
No problem at all! Just wanted to update on my integration. Also - i'm not sure how to keep this working -- there are certain indices in the /db/schema.rb file which cause the test migrations to fail and thus the tests to error out. I had commented them out but think i messed it up and deleted them in the merge... totally my fault, but just be aware that the current version of schema.rb has some commented out index definitions which are required for tests to run.
On Thu, Apr 11, 2013 at 10:50 AM, Bryan Bonvallet notifications@github.comwrote:
Good find. I have no doubt I would make a mistake like that. The "rocket" is a strange symbol to be forced to type all the time; it harkens back to the day where := (set) was different from = (equals).
Sorry I haven't built tests for Likes yet. I have negotiated contract work with a company which semi-officially began on Monday. Once I have Rails testing down, I should be in a good position to tackle the next task for the website much more quickly.
On Thu, Apr 11, 2013 at 10:47 AM, Jeffrey Warren notifications@github.comwrote:
whoops, found one small bug which tripped an error in production on the live server, but not in development. Probably because production preloads more stuff and tripped it up front...
belongs_to :other, :class_name = :User, :foreign_key => 'other_id'
should have been
belongs_to :other, :class_name => :User, :foreign_key => 'other_id'
on line 5 of user_selection.rb
just noting it here, my fix is in the next commit. All else seems perfect and now running on publiclab.org!
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16239122>
.
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16246999> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16256536> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16257027> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16345720> .
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16346170 .
jywarren
commented
11 years ago is the test db set to use sqlite/sqlite3 in your database.yml file? I set it to use mysql.
On Sun, Apr 14, 2013 at 1:21 AM, Bryan Bonvallet notifications@github.comwrote:
I can't get the tests to run, by the way. It looks like we were talking about that in this thread. There is an error with spatial adapter not supporting sqlite, and it looks like nothing else is tried so far as I can tell.
I pulled from the repo and tested about the time you sent your previous email. Is
rake testnot the right way to run the tests?On Sun, Apr 14, 2013 at 1:13 AM, Bryan btbonval@gmail.com wrote:
I thought about something like that myself, but it was from a purely functional standpoint of showing a user his or her own likes. What you made is much prettier than what I would have come up with and makes it easy to share your likes with others.
I just noticed something: the little summary bar with the by-line, date, comment count, and like count. I think I might try modifying that so the like indicator can be used to like/unlike directly from the summary views.
On Sun, Apr 14, 2013 at 12:16 AM, Jeffrey Warren < notifications@github.com
wrote:
Super; I added a "likes page" for each user: http://publiclab.org/profile/warren/likes On Apr 11, 2013 5:04 PM, "Jeffrey Warren" jeff@unterbahn.com wrote:
agreed re: more research. My understanding has always been that it reflects Rails' current understanding/awareness of the database, and that it is typically generated upon running rake db:migrate. In our hijacking a Drupal database, it seems that this assumption may not exactly hold.
On Thu, Apr 11, 2013 at 1:49 PM, Bryan Bonvallet < notifications@github.com
wrote:
What does schema.rb do? It seems to be a reflection of the current database schema, but that's all in the database. I'm surprised commenting things out in that file make a difference for testing. If that file only reflects the database, the migrations should be able to reconstruct that anyway, and we don't even need to track it. If schema.rb does something more integral to Rails, we should probably figure out what it does and why it's causing test problems.
On Thu, Apr 11, 2013 at 3:40 PM, Jeffrey Warren < notifications@github.com>wrote:
No problem at all! Just wanted to update on my integration. Also - i'm not sure how to keep this working -- there are certain indices in the /db/schema.rb file which cause the test migrations to fail and thus the tests to error out. I had commented them out but think i messed it up and deleted them in the merge... totally my fault, but just be aware that the current version of schema.rb has some commented out index definitions which are required for tests to run.
On Thu, Apr 11, 2013 at 10:50 AM, Bryan Bonvallet notifications@github.comwrote:
Good find. I have no doubt I would make a mistake like that. The "rocket" is a strange symbol to be forced to type all the time; it harkens back to the day where := (set) was different from = (equals).
Sorry I haven't built tests for Likes yet. I have negotiated contract work with a company which semi-officially began on Monday. Once I have Rails testing down, I should be in a good position to tackle the next task for the website much more quickly.
On Thu, Apr 11, 2013 at 10:47 AM, Jeffrey Warren notifications@github.comwrote:
whoops, found one small bug which tripped an error in production on the live server, but not in development. Probably because production preloads more stuff and tripped it up front...
belongs_to :other, :class_name = :User, :foreign_key => 'other_id'
should have been
belongs_to :other, :class_name => :User, :foreign_key => 'other_id'
on line 5 of user_selection.rb
just noting it here, my fix is in the next commit. All else seems perfect and now running on publiclab.org!
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16239122>
.
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16246999> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16256536> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16257027> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16345720> .
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16346223 .
btbonval
commented
11 years ago That'd be the problem. I'll make some notes about that in the README.environment.
Can you paste your database.yml section for testing? I'm curious how you set it up to test in a clean environment.
On Sun, Apr 14, 2013 at 1:22 AM, Jeffrey Warren notifications@github.comwrote:
is the test db set to use sqlite/sqlite3 in your database.yml file? I set it to use mysql.
On Sun, Apr 14, 2013 at 1:21 AM, Bryan Bonvallet notifications@github.comwrote:
I can't get the tests to run, by the way. It looks like we were talking about that in this thread. There is an error with spatial adapter not supporting sqlite, and it looks like nothing else is tried so far as I can tell.
I pulled from the repo and tested about the time you sent your previous email. Is
rake testnot the right way to run the tests?On Sun, Apr 14, 2013 at 1:13 AM, Bryan btbonval@gmail.com wrote:
I thought about something like that myself, but it was from a purely functional standpoint of showing a user his or her own likes. What you made is much prettier than what I would have come up with and makes it easy to share your likes with others.
I just noticed something: the little summary bar with the by-line, date, comment count, and like count. I think I might try modifying that so the like indicator can be used to like/unlike directly from the summary views.
On Sun, Apr 14, 2013 at 12:16 AM, Jeffrey Warren < notifications@github.com
wrote:
Super; I added a "likes page" for each user: http://publiclab.org/profile/warren/likes On Apr 11, 2013 5:04 PM, "Jeffrey Warren" jeff@unterbahn.com wrote:
agreed re: more research. My understanding has always been that it reflects Rails' current understanding/awareness of the database, and that it is typically generated upon running rake db:migrate. In our hijacking a Drupal database, it seems that this assumption may not exactly hold.
On Thu, Apr 11, 2013 at 1:49 PM, Bryan Bonvallet < notifications@github.com
wrote:
What does schema.rb do? It seems to be a reflection of the current database schema, but that's all in the database. I'm surprised commenting things out in that file make a difference for testing. If that file only reflects the database, the migrations should be able to reconstruct that anyway, and we don't even need to track it. If schema.rb does something more integral to Rails, we should probably figure out what it does and why it's causing test problems.
On Thu, Apr 11, 2013 at 3:40 PM, Jeffrey Warren < notifications@github.com>wrote:
No problem at all! Just wanted to update on my integration. Also
i'm not sure how to keep this working -- there are certain indices in the /db/schema.rb file which cause the test migrations to fail and thus the tests to error out. I had commented them out but think i messed it up and deleted them in the merge... totally my fault, but just be aware that the current version of schema.rb has some commented out index definitions which are required for tests to run.
On Thu, Apr 11, 2013 at 10:50 AM, Bryan Bonvallet notifications@github.comwrote:
Good find. I have no doubt I would make a mistake like that. The "rocket" is a strange symbol to be forced to type all the time; it harkens back to the day where := (set) was different from = (equals).
Sorry I haven't built tests for Likes yet. I have negotiated contract work with a company which semi-officially began on Monday. Once I have Rails testing down, I should be in a good position to tackle the next task for the website much more quickly.
On Thu, Apr 11, 2013 at 10:47 AM, Jeffrey Warren notifications@github.comwrote:
whoops, found one small bug which tripped an error in production on the live server, but not in development. Probably because production preloads more stuff and tripped it up front...
belongs_to :other, :class_name = :User, :foreign_key => 'other_id'
should have been
belongs_to :other, :class_name => :User, :foreign_key => 'other_id'
on line 5 of user_selection.rb
just noting it here, my fix is in the next commit. All else seems perfect and now running on publiclab.org!
— Reply to this email directly or view it on GitHub<
https://github.com/jywarren/plots2/pull/88#issuecomment-16239122>
.
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16246999>
.
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16256536> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16257027> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16345720> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16346223> .
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16346239 .
jywarren
commented
11 years ago i made it the same as production or development -- "mysql" but gave it its own "publiclab_test" database to play in. I'm not actually on my dev computer right now... we should also make the database.yml.example file reflect a mysql test db.
On Sun, Apr 14, 2013 at 1:24 AM, Bryan Bonvallet notifications@github.comwrote:
That'd be the problem. I'll make some notes about that in the README.environment.
Can you paste your database.yml section for testing? I'm curious how you set it up to test in a clean environment.
On Sun, Apr 14, 2013 at 1:22 AM, Jeffrey Warren notifications@github.comwrote:
is the test db set to use sqlite/sqlite3 in your database.yml file? I set it to use mysql.
On Sun, Apr 14, 2013 at 1:21 AM, Bryan Bonvallet notifications@github.comwrote:
I can't get the tests to run, by the way. It looks like we were talking about that in this thread. There is an error with spatial adapter not supporting sqlite, and it looks like nothing else is tried so far as I can tell.
I pulled from the repo and tested about the time you sent your previous email. Is
rake testnot the right way to run the tests?On Sun, Apr 14, 2013 at 1:13 AM, Bryan btbonval@gmail.com wrote:
I thought about something like that myself, but it was from a purely functional standpoint of showing a user his or her own likes. What you made is much prettier than what I would have come up with and makes it easy to share your likes with others.
I just noticed something: the little summary bar with the by-line, date, comment count, and like count. I think I might try modifying that so the like indicator can be used to like/unlike directly from the summary views.
On Sun, Apr 14, 2013 at 12:16 AM, Jeffrey Warren < notifications@github.com
wrote:
Super; I added a "likes page" for each user: http://publiclab.org/profile/warren/likes On Apr 11, 2013 5:04 PM, "Jeffrey Warren" jeff@unterbahn.com wrote:
agreed re: more research. My understanding has always been that it reflects Rails' current understanding/awareness of the database, and that it is typically generated upon running rake db:migrate. In our hijacking a Drupal database, it seems that this assumption may not exactly hold.
On Thu, Apr 11, 2013 at 1:49 PM, Bryan Bonvallet < notifications@github.com
wrote:
What does schema.rb do? It seems to be a reflection of the current database schema, but that's all in the database. I'm surprised commenting things out in that file make a difference for testing. If that file only reflects the database, the migrations should be able to reconstruct that anyway, and we don't even need to track it. If schema.rb does something more integral to Rails, we should probably figure out what it does and why it's causing test problems.
On Thu, Apr 11, 2013 at 3:40 PM, Jeffrey Warren < notifications@github.com>wrote:
No problem at all! Just wanted to update on my integration.
Also
i'm not sure how to keep this working -- there are certain indices in the /db/schema.rb file which cause the test migrations to fail and thus the tests to error out. I had commented them out but think i messed it up and deleted them in the merge... totally my fault, but just be aware that the current version of schema.rb has some commented out index definitions which are required for tests to run.
On Thu, Apr 11, 2013 at 10:50 AM, Bryan Bonvallet notifications@github.comwrote:
Good find. I have no doubt I would make a mistake like that. The "rocket" is a strange symbol to be forced to type all the time; it harkens back to the day where := (set) was different from = (equals).
Sorry I haven't built tests for Likes yet. I have negotiated contract work with a company which semi-officially began on Monday. Once I have Rails testing down, I should be in a good position to tackle the next task for the website much more quickly.
On Thu, Apr 11, 2013 at 10:47 AM, Jeffrey Warren notifications@github.comwrote:
whoops, found one small bug which tripped an error in production on the live server, but not in development. Probably because production preloads more stuff and tripped it up front...
belongs_to :other, :class_name = :User, :foreign_key => 'other_id'
should have been
belongs_to :other, :class_name => :User, :foreign_key => 'other_id'
on line 5 of user_selection.rb
just noting it here, my fix is in the next commit. All else seems perfect and now running on publiclab.org!
— Reply to this email directly or view it on GitHub<
https://github.com/jywarren/plots2/pull/88#issuecomment-16239122>
.
— Reply to this email directly or view it on GitHub<
https://github.com/jywarren/plots2/pull/88#issuecomment-16246999>
.
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16256536>
.
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16257027> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16345720> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16346223> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16346239> .
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16346259 .
btbonval
commented
11 years ago I didn't realize there was an example file; I had put a skeleton in the README.environment. Those instructions should be good enough for me to push through this and submit a fix to help other devs.
On Sun, Apr 14, 2013 at 1:26 AM, Jeffrey Warren notifications@github.comwrote:
i made it the same as production or development -- "mysql" but gave it its own "publiclab_test" database to play in. I'm not actually on my dev computer right now... we should also make the database.yml.example file reflect a mysql test db.
On Sun, Apr 14, 2013 at 1:24 AM, Bryan Bonvallet notifications@github.comwrote:
That'd be the problem. I'll make some notes about that in the README.environment.
Can you paste your database.yml section for testing? I'm curious how you set it up to test in a clean environment.
On Sun, Apr 14, 2013 at 1:22 AM, Jeffrey Warren < notifications@github.com>wrote:
is the test db set to use sqlite/sqlite3 in your database.yml file? I set it to use mysql.
On Sun, Apr 14, 2013 at 1:21 AM, Bryan Bonvallet notifications@github.comwrote:
I can't get the tests to run, by the way. It looks like we were talking about that in this thread. There is an error with spatial adapter not supporting sqlite, and it looks like nothing else is tried so far as I can tell.
I pulled from the repo and tested about the time you sent your previous email. Is
rake testnot the right way to run the tests?On Sun, Apr 14, 2013 at 1:13 AM, Bryan btbonval@gmail.com wrote:
I thought about something like that myself, but it was from a purely functional standpoint of showing a user his or her own likes. What you made is much prettier than what I would have come up with and makes it easy to share your likes with others.
I just noticed something: the little summary bar with the by-line, date, comment count, and like count. I think I might try modifying that so the like indicator can be used to like/unlike directly from the summary views.
On Sun, Apr 14, 2013 at 12:16 AM, Jeffrey Warren < notifications@github.com
wrote:
Super; I added a "likes page" for each user: http://publiclab.org/profile/warren/likes On Apr 11, 2013 5:04 PM, "Jeffrey Warren" jeff@unterbahn.com wrote:
agreed re: more research. My understanding has always been that it reflects Rails' current understanding/awareness of the database, and that it is typically generated upon running rake db:migrate. In our hijacking a Drupal database, it seems that this assumption may not exactly hold.
On Thu, Apr 11, 2013 at 1:49 PM, Bryan Bonvallet < notifications@github.com
wrote:
What does schema.rb do? It seems to be a reflection of the current database schema, but that's all in the database. I'm surprised commenting things out in that file make a difference for testing. If that file only reflects the database, the migrations should be able to reconstruct that anyway, and we don't even need to track it. If schema.rb does something more integral to Rails, we should probably figure out what it does and why it's causing test problems.
On Thu, Apr 11, 2013 at 3:40 PM, Jeffrey Warren < notifications@github.com>wrote:
No problem at all! Just wanted to update on my integration.
Also
i'm not sure how to keep this working -- there are certain indices in the /db/schema.rb file which cause the test migrations to fail and thus the tests to error out. I had commented them out but think i messed it up and deleted them in the merge... totally my fault, but just be aware that the current version of schema.rb has some commented out index definitions which are required for tests to run.
On Thu, Apr 11, 2013 at 10:50 AM, Bryan Bonvallet notifications@github.comwrote:
Good find. I have no doubt I would make a mistake like that. The "rocket" is a strange symbol to be forced to type all the time; it harkens back to the day where := (set) was different from = (equals).
Sorry I haven't built tests for Likes yet. I have negotiated contract work with a company which semi-officially began on Monday. Once I have Rails testing down, I should be in a good position to tackle the next task for the website much more quickly.
On Thu, Apr 11, 2013 at 10:47 AM, Jeffrey Warren notifications@github.comwrote:
whoops, found one small bug which tripped an error in production on the live server, but not in development. Probably because production preloads more stuff and tripped it up front...
belongs_to :other, :class_name = :User, :foreign_key => 'other_id'
should have been
belongs_to :other, :class_name => :User, :foreign_key => 'other_id'
on line 5 of user_selection.rb
just noting it here, my fix is in the next commit. All else seems perfect and now running on publiclab.org!
— Reply to this email directly or view it on GitHub<
https://github.com/jywarren/plots2/pull/88#issuecomment-16239122>
.
— Reply to this email directly or view it on GitHub<
https://github.com/jywarren/plots2/pull/88#issuecomment-16246999>
.
— Reply to this email directly or view it on GitHub<
https://github.com/jywarren/plots2/pull/88#issuecomment-16256536>
.
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16257027>
.
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16345720> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16346223> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16346239> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16346259> .
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16346277 .
btbonval
commented
11 years ago There is definitely an example database yaml, but it does use SQLite for test. I'll update it with some other notes.
On Sun, Apr 14, 2013 at 1:27 AM, Bryan btbonval@gmail.com wrote:
I didn't realize there was an example file; I had put a skeleton in the README.environment. Those instructions should be good enough for me to push through this and submit a fix to help other devs.
On Sun, Apr 14, 2013 at 1:26 AM, Jeffrey Warren notifications@github.comwrote:
i made it the same as production or development -- "mysql" but gave it its own "publiclab_test" database to play in. I'm not actually on my dev computer right now... we should also make the database.yml.example file reflect a mysql test db.
On Sun, Apr 14, 2013 at 1:24 AM, Bryan Bonvallet notifications@github.comwrote:
That'd be the problem. I'll make some notes about that in the README.environment.
Can you paste your database.yml section for testing? I'm curious how you set it up to test in a clean environment.
On Sun, Apr 14, 2013 at 1:22 AM, Jeffrey Warren < notifications@github.com>wrote:
is the test db set to use sqlite/sqlite3 in your database.yml file? I set it to use mysql.
On Sun, Apr 14, 2013 at 1:21 AM, Bryan Bonvallet notifications@github.comwrote:
I can't get the tests to run, by the way. It looks like we were talking about that in this thread. There is an error with spatial adapter not supporting sqlite, and it looks like nothing else is tried so far as I can tell.
I pulled from the repo and tested about the time you sent your previous email. Is
rake testnot the right way to run the tests?On Sun, Apr 14, 2013 at 1:13 AM, Bryan btbonval@gmail.com wrote:
I thought about something like that myself, but it was from a purely functional standpoint of showing a user his or her own likes. What you made is much prettier than what I would have come up with and makes it easy to share your likes with others.
I just noticed something: the little summary bar with the by-line, date, comment count, and like count. I think I might try modifying that so the like indicator can be used to like/unlike directly from the summary views.
On Sun, Apr 14, 2013 at 12:16 AM, Jeffrey Warren < notifications@github.com
wrote:
Super; I added a "likes page" for each user: http://publiclab.org/profile/warren/likes On Apr 11, 2013 5:04 PM, "Jeffrey Warren" jeff@unterbahn.com wrote:
agreed re: more research. My understanding has always been that it reflects Rails' current understanding/awareness of the database, and that it is typically generated upon running rake db:migrate. In our hijacking a Drupal database, it seems that this assumption may not exactly hold.
On Thu, Apr 11, 2013 at 1:49 PM, Bryan Bonvallet < notifications@github.com
wrote:
What does schema.rb do? It seems to be a reflection of the current database schema, but that's all in the database. I'm surprised commenting things out in that file make a difference for testing. If that file only reflects the database, the migrations should be able to reconstruct that anyway, and we don't even need to track it. If schema.rb does something more integral to Rails, we should probably figure out what it does and why it's causing test problems.
On Thu, Apr 11, 2013 at 3:40 PM, Jeffrey Warren < notifications@github.com>wrote:
No problem at all! Just wanted to update on my integration.
Also
i'm not sure how to keep this working -- there are certain indices in the /db/schema.rb file which cause the test migrations to fail and thus the tests to error out. I had commented them out but think i messed it up and deleted them in the merge... totally my fault, but just be aware that the current version of schema.rb has some commented out index definitions which are required for tests to run.
On Thu, Apr 11, 2013 at 10:50 AM, Bryan Bonvallet notifications@github.comwrote:
Good find. I have no doubt I would make a mistake like that. The "rocket" is a strange symbol to be forced to type all the time; it harkens back to the day where := (set) was different from = (equals).
Sorry I haven't built tests for Likes yet. I have negotiated contract work with a company which semi-officially began on Monday. Once I have Rails testing down, I should be in a good position to tackle the next task for the website much more quickly.
On Thu, Apr 11, 2013 at 10:47 AM, Jeffrey Warren notifications@github.comwrote:
whoops, found one small bug which tripped an error in production on the live server, but not in development. Probably because production preloads more stuff and tripped it up front...
belongs_to :other, :class_name = :User, :foreign_key => 'other_id'
should have been
belongs_to :other, :class_name => :User, :foreign_key => 'other_id'
on line 5 of user_selection.rb
just noting it here, my fix is in the next commit. All else seems perfect and now running on publiclab.org!
— Reply to this email directly or view it on GitHub<
https://github.com/jywarren/plots2/pull/88#issuecomment-16239122>
.
— Reply to this email directly or view it on GitHub<
https://github.com/jywarren/plots2/pull/88#issuecomment-16246999>
.
— Reply to this email directly or view it on GitHub<
https://github.com/jywarren/plots2/pull/88#issuecomment-16256536>
.
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16257027>
.
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16345720> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16346223> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16346239> .
— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/pull/88#issuecomment-16346259> .
— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/pull/88#issuecomment-16346277 .
I got the Like button working in this branch and I've merged it with your repo.
Last time I submitted a pull request, I don't think my changes actually got integrated for some reason. After you pull, see if the Like button can be clicked on a random page.
fixes ticket #74