Major change planned for Property Bee on daft.ie

[Mods could you leave this here for awhile please before moving it to Online Resources & Tracking tools, as I would like to get as much feedback as possible from daft users before I make this major change to Property Bee. Thanks]

As some of you maybe aware property bee has some issues on daft due to the reuse / non uniqueness of the ids used on the site.

For the next release of property bee (hopefully before Christmas), I want to solve this problem for once and all!

Now this is never going to be a easy fix, so I want to pass my idea before you all to make sure I’ve got it right and not missed anything obvious.

Currently PB uses the id in the properties url to identify which property the user is looking at. This has 2 problems;

  • the same id can be used for properies for sale or rent (this is why the history shows changes for unrelated properties)

  • the id appears to be reused in some cases (ie a property for sale changes to a completely different property)

For PB to really work properly it really needs an id which is unique to that property.

Hence I’m proposing that PB changes the way it identifies all properties on daft, as follows;

For the url daft.ie/1530722) and we append the first part of the properties title (29 Seapark, Malahide, Co Dublin, Malahide, Co. Dublin) to the end.

This new reference number of “df1530772-29 Seapark” should be unique enough to apply only to this property, which would mean that the history displayed by PB will only show information for that property.

The downside is this is a “big bang” change… ie it will be a fresh start and all current history will be lost.

My personal feeling is that we need to go through the pain of doing this so that PB works as it should on daft, but it really down to you whether you guys…

So what you think? Big bang or not?

Thanks
BH

Hey BH,
Personally I don’t like the idea of losing data.

Does daft reuse codes or is it estate agents/landlords. My assumption was that certain agents (or landlords) were completely editing a unique entry (attached to a code), changing the address, text photos etc, so that “4 bed house Ballsbridge €1.1m” becomes “1 bed apartment Finglas €700pm”.

In which case you could assign a new unique code if a property is updated e.g. df530722 becomes df530722-29 Seapark, but you would still display the history for both of those codes combined.

In time, more new properties would be entered, with codes that would have your new unique df530722-29 Seapark format anyway, which would be immune to the “complete edit” issue

Also do these codes eventually expire (e.g. daft disable a code after a year), in which case the entries displayed based on combined old and new codes would disappear relatively quickly.

Let me know if I’ve gotten anything wrong or failed to explain myself properly.
:neutral_face:

Hi blah,

To be honest I was expecting that answer, but no harm in trying to pitch the simple solution first is there :angry:

There is a bug in property bee which causes a majority of these edits… for example df530722 is also is used by (if it exists) the commerical property with id 30722 (whose shortcode happens to be 530722) on daft - its this horrible mess in PB which definately needs fixing and it makes my head hurt :blush:

The cases where a property for sale becomes a completely different property for sale (similarly for rentals et al) are definitely edits by daft/agent/landlords. I thought I’d seen a few of these, but now I look I can’t find any…

That is very similar to an approach I was looking at;

  • keep the existing history using the old codes
  • as properties are viewed they get migrated across to the new code
  • eventually you’ll end up with all new codes, and no old codes but still have a complete history

I’ve still some investigation to do on whether this is feasible, but at the moment its probably the most likely and workable approach.

At the moment PB doesn’t detect expired codes on daft (although I’m hoping to add the feature early next year) which currently means PB has no means of removing old codes…

Thanks blah, you made perfect sense, and I similar hope that I make sense!

Cheers
BH

Very infrequent poster here but I do use the property bee plugin.

You may already have this structure in place in your database but can I suggest that you use a separate primary key in your table of properties, to the unique identifier that you’re trying to define here. You have very little control over what this identifier may have to become over time, since you have no control over the Daft website.

Within your database all joins should be based on an internal primary key - probably a simple integer serial - and then the identifier to link a property to an entry on Daft can be easily adapted over time if there are further changes to Daft.

With all of the above I am quite possibly “teaching my Grandmother to suck eggs” so to speak.

Your second approach to migrating the data over time as entries are pulled up sounds supremely better than the first. Losing the history effectively means restarting the Property Bee from scratch when the most valuable thing you have is all of your existing harvested data.

I have a concern that I regularly see the “title” of a property getting changed on Daft. “22 Somewhere Lane” becoming “Somewhere Lane” or “22 - Somewhere Rd.” and so on. Is there no way to figure out whether you are looking at commercial, lettings or sales? I understand theres also the problem of re-use of identifiers.

Tough one. Please don’t lose the history! :slight_smile:

Edit: Just took a look at the Daft page source… We can tell whether its “Sales”, “Commercial”, “Lettings”, etc. from a div called “linkbar”. One of the list items is given a class called “active”. I think distinguishing between these would solve a big part of the confused histories. The majority of confused histories that I have seen have been a crossover from a Lettings entry to a Sales entry.

I’m probably throwing a lot of ideas around that have been thrashed out before. Sorry if I’m coming in new and hashing out old debunked ideas.

Hi

Thats exactly what I have (the slighty strange syntax is due to the underlying database being sqlite);

CREATE TABLE `Property` (
    `Property_ID` INTEGER PRIMARY KEY  NOT NULL , 
    `Reference` VARCHAR NOT NULL, -- This the string generated from the id from the webpage
    -- 
)
CREATE UNIQUE INDEX 'Idx_Property_Reference' ON 'Property' (Reference ASC)

CREATE TABLE `Sample` (
    `Sample_ID` INTEGER PRIMARY KEY  NOT NULL , 
    `Property_ID` INTEGER NOT NULL , 
    `Sampled_On` DATETIME NOT NULL , 
    -- 
)
CREATE INDEX 'Idx_Sample_Property_ID' ON 'Sample' (Property_ID ASC)

Agreeded, and I’m putting all my effort into making the migration approach work.

That is a concern, and I’m starting to wonder if PB should just use the daft shortcode as the unique id and not worry whether or not agents/landlords reuse the same daft shortcode.

Yes there is a way… and some baggage;

When PB first started, I wrongly assumed that the ids in the url were unique. Then a few years ago when it became clear they weren’t some investigation was done between the relationship between the id in the url and the corresponding daft shortcode link found in the properties details (which must be unique for daft to direct you to the right page). I found that the shortcode was the id prefixed with a digit which depends on the type of property (or webpage filename);

searchsale.daft: ‘1’
searchrental.daft: ‘2’
searchsharing.daft: ‘3’
searchcommercial.daft: ‘5’
searchshortterm.daft: ‘6’
searchinternational_sale.daft: ‘7’
searchinternational_rental.daft: ‘8’

ie for daft.ie/searchcommercial.daft?id=530722 the shortcode is 5530722

Now unfortunately when I made the orginal fix for this (many years ago), I cocked up… the prefix was added for all properties correctly except those for sale (searchsale.daft) where no prefix was added - which means we still have the case where a property for sale with the id 234 shares the same history as a property to rent with the id 34.

Hence the position we are in today.

No thanks, actually having to explain what has happened makes it clearer in my head what needs to be done… even if no one understands my ramblings :laughing:

I was right so. You are on top of it all. :slight_smile:

I think fixing the inclusion of one of the possible indicators of “Lettings”, “Sales”, “Commercial”, etc. is going to reduce confused histories by at least 75% and should appear pretty seamless to the users.

Well done on the property bee overall by the way! I wish I still had the interest in coding, and the dedication required to take on something like that myself.

Is there any point in pm’ing Ronan Lyons who posts here frequently. You could come to agreement with the daft.ie team regarding unique identifiers. Property Bee would greatly enhance the functionality of the site.

Good news, I’ve just finished implementing the migration of daft properties (from dfxxx to daftyyyy where xxx is the old non-unique id and yyyy is the daft shortcode), it works and keeps all the old history BD

Mid next week (21st) I plan to do a release candidate, so anyone wanting to test it out should keep an eye out on property-bee.com/forum/viewt … 15&t=10866.

Assuming all goes well, an official release is planned approximately a week later (28th)

Cheers, and Happy Christmas everyone
BH

ps Mods feel free to move this thread to Online Resources & Tracking tools