- Development - lists.drupal.org

Re: [development] Have you ever laughed fate in the face?
by Chad Phillips -- Apartment Lines 20 Jul '06

20 Jul '06

On Jul 20, 2006, at 11:26 AM, Dries wrote: > My problem with the trashbin patch is the way it works. I'm not > convinced that it should transfer deleted records to a dedicated > table. Right now, the trashbin patch stores deleted records in a > separate table in serialized format. not exactly. there is no serialization involved. the deleted_data table stores data one row per column for each row of data deleted from the table. kind of expensive for large deletions, i know... > This is a little bit awkward as it has to circumvent the auto > increment IDs or the sequence table when re-injecting the data. correct, although i haven't seen that to be a problem, since we never go backwards. the data slips right back into where it was. > > Why don't we add a status-field with two states -- STATUS_ACTIVE > and STATUS_DELETED -- to each of the database tables with records > that want to take advantage of the trashbin functionality? Then, > the trashbin patch might be a lot easier to grok -- and from an > architectural point of view, less awkward. It wouldn't be > particularly clever but that is OK: it is super-easy so there is no > point being clever to begin with. I'd like to see us explore this > path instead. this would be great, but as i've said before we'll need an SQL query engine in core (or at least functionality that can handle all of the ins and outs of filtering out the deleted data automagically, but allowing access to it when necessary, etc.). also, i think we need to consider how contrib modules will interact with this. will we require a status field in all database tables, or maybe have core auto-add one if it's not already present? the current approach while a little awkward is able to work around all of this. > > Plus, this has a number of advantages. Most of all, we'd still > able to query deleted data. For example, the filter form on the > administer content page (?q=admin/content) would allow us to access > delete nodes and we'd be able to use advanced query methods like > 'show all deleted nodes from user Joe with the taxonomy term > 'Apple'. That is, we get to reuse a lot of the existing UIs and > modules. yes, this would be great as well...

1 0

DrupalCON Europe
by Dries Buytaert 20 Jul '06

20 Jul '06

Hello, as you might have read, we started planning this year's DrupalCON Europe. We're currently looking for a venue, and would like to know what the 'ideal setup' looks like in terms of meeting rooms and presentation rooms. Please share you ideas at http:// groups.drupal.org/node/363#comment-1371. Your input is required to move forward. -- Dries Buytaert :: http://www.buytaert.net/

2 1

Drop MySQL 3 support
by Gerhard Killesreiter 20 Jul '06

20 Jul '06

Hi there! MySQL AB (the company behind our most used database) has announced a change in support options for their database products. http://www.mysql.com/company/legal/mysql_lifecycle_policy.pdf According to this document, the active support for MySQL 3.23 will end at the last of this month (ie on two weeks) and the extended support will end on the end of this year. I therefore propose that we formally drop support of MySQL 3 as of Drupal 4.8 which will appear later this year. MySQl 4.0's active support will end the last of September, we could consider dropping support for it too. Extended support will run until the end of 2008. Dropping both MySQL 3 and 4.0 would enable us to rewrite some parts of our SQL queries. The extend of this would need to be researched. I know that people will argue with "but there are so many ISPs that still run 3.23". ISPs that still run 3.23 after it has been retired by the supporting company are probably not worth the money you them. Cheers, Gerhard

17 20

Re: [development] Deleted records [Have you ever laughed fate in the face?]
by Chad Phillips -- Apartment Lines 20 Jul '06

20 Jul '06

On Jul 20, 2006, at 6:00 AM, Farsheed wrote: > How is this different than "unpublishing" a node? > Perhaps the Delete button should become an Unpublish > button. > > Then an admin would use the regular admin interface if > a node needed permanent deletion. that accounts for node data, but what about other kinds of deletions? how are they to be handled?

1 0

Re: [development] Deleted records [Have you ever laughed fate in the face?]
by Chad Phillips -- Apartment Lines 20 Jul '06

20 Jul '06

On Jul 20, 2006, at 6:00 AM, sime wrote: > So just for the record, I would like a "deleted" column in Drupal. i would love to do that--it would be a far more elegant approach than the current trashbin code uses. but after a lot of analysis, i concluded that without a proper SQL query engine in core to pass things through, it would be a mess--especially considering that contrib modules don't have the same strict requirements as core...

1 0

Re: [development] Deleted records [Have you ever laughed fate in the face?]
by Chad Phillips -- Apartment Lines 20 Jul '06

20 Jul '06

On Jul 20, 2006, at 6:00 AM, Adrian wrote: > What I think would be cool... is if you had the db_create_table > function, to > spawn new derivative tables. > > ie: node_deleted (or node_archived) , etc. > > The logic for applying updates to trash binned content can become > very complex though =( i considered this approach, but did abandon it at the time because of the complexity. atm, the trashbin patch wipes the trash data when a user performs a db update, which is an easy way to avoid corrupted data, although not as elegant as it could be... :)

1 0

where has database/updates.inc gone to?
by Augustin (Beginner) 19 Jul '06

19 Jul '06

where has database/updates.inc gone to? -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.

1 1

Knowing who the users are
by Neil Drumm 19 Jul '06

19 Jul '06

This came out of a different thread; I think it is best to start a fresh one for this. Figuring out who Drupal's users are creates a good tool for us as developers. We could ask ourselves "what would Drupal deployers think about this?" and have better answers. Basically we would need to get a general idea of what sorts of users are out there, slice those up into categories, and write up good descriptions of the categories. Descriptions would include things like - computer experience - internet use - job description - Drupal use - high-level goals for Drupal To go a step further, we could create a persona for each category of users; a writeup of a fictional user in the category. Then our on of our questions would become "what would Jim the Drupal deployer think about this?" It helps the generalized categories become human again. This has been suggested independently by jibbajabba, http://groups.drupal.org/node/763#comment-2515. We already have a basic set established by the old administration user survey at question 2.1 of http://www.surveymonkey.com/DisplaySummary.asp?SID=1425065&U=142506581557. However, these results are somewhere around 10 months old in a time of exponential growth and the notes on interviews used to arrive a these categories have been lost. But they are relatively sane and better than nothing, so I'll use them when I need to cover our user-base in broad strokes until there is something better. -- Neil Drumm http://delocalizedham.com/

1 0

RE: [development] what's a "user"? (was re: Have you ever laughedfate in the face?)
by Steven Peck 19 Jul '06

19 Jul '06

General commentary. For what it's worth. The definition for several years has been 'user', person who uses Drupal to build sites. The person who uses your site is 'your' user, audience or customer depending on your site. :D This is something that the vast majority of the documentation is setup for (not all). I keep forgetting that it needs to be written down somewhere for people. That said, periodic discussions about 'end users', ease of use and better interfaces, etc happen all the time. Each time things generally get a little better for both 'users' and various other audiences. Better interfaces in general provide better tools for 'users' to use to implement their site. Unfortunatly, the words are pretty accurate for the context in which they are used, but because they are from a certain perspective there aren't a lot of different words to define 'end user' unless we start using long phrases like site's target audience, etc.... -sp > -----Original Message----- > From: development-bounces(a)drupal.org > [mailto:development-bounces@drupal.org] On Behalf Of Bèr Kessels snipped > And FWIW: I count myself as a Drupal user. My clients never > (should) need to > know they are Drupal users. They use a site. They really > don't care what > stuff is behind it. > > Bèr

1 0

Re: [development] what's a "user"?
by Chad Phillips -- Apartment Lines 19 Jul '06

19 Jul '06

On Jul 18, 2006, at 6:17 PM, Ber wrote: > Take views, or cck: They are very complex, but I can learn it once, > and my > clients never need to learn it. So why simplify views to make it > more "usable"? All my client sees is a table with all his products > in it. He > never needs to know that I fought with views exports. That I digged > for the > proper CCK field setting. i'm a bit confused why the discussion seems to be that we have to do one or the other. what i would _love_ to see from the standpoint of configuration options is an approach where you keep things very simple on the surface, making the decisions that would be best for the 'typical' user, then if somebody reeeeeaaaallly wants to change every little thing, they click an 'advanced settings' button or something, and they can customize to their hearts delight. of course, the ultimate in customization is to crack into the code, but i think it would be nice if we had another layer or two in between... :)

1 0