Possible incompatibility when inserting new entries via mapper on PostgreSQL

[sn0opy]

As reported by @stehlo1. There seems to be an issue with this change. f3-factory/fatfree-core@5ba562f

@stehlo1 please commend below with a proper error description.

[ikkez]

there's nothing screwed-up... if there's an issue with postgreSQL, we will find it... but no one it helped when you spread your anger around here.

[sn0opy]

It was a fix for an issue that has clearly not being tested with PostgreSQL. Now please post the actual problem instead of blaming people for not testing stuff beforehand.

[ikkez]

@stehlo1 you don't need write in your comments that you'll delete them shortly... I can do that for you! Please only post comments that'll help solving the issue and are fine to be archived.

[GhaziTriki]

Hello Guys,

I confirm that with 3.7.2 release there is a problem with PostgreSQL mapping, after inserting a new entry the fields values are set to null.

[slavino]

Exactly.

In PostgreSQL 9.6 when I call
$entity->save();

in Release 3.7.2 it behaves similar to
$entity->save() && $entity->reset();

after saving the entry properly. So I have to do the extra step - load the entity by some other Unique identificator (if any available) :-/

Initial setup:
$db = new DB\SQL(
$f3->get('devdb'),
$f3->get('devdbusername'),
$f3->get('devdbpassword'),
array( \PDO::ATTR_ERRMODE => \PDO::ERRMODE_EXCEPTION)
);

[didiergm]

Going from release 3.6 to 3.7-3-dev from 2 days ago. PostgreSQL 10 & 11
I had to change some pieces of code all over an existing app 👍

   $this->scenario = new DB\SQL\Mapper($this->db, 'scenarios');
   if ((integer) $f3->get('POST.id') == -1)
     $id = NULL;
   else {
     $id = (integer) $f3->get('POST.id');
    $this->scenario->load(array('id=?', $id));
    }
   $this->scenario->id = $id;
    $this->scenario->code = $f3->get('POST.code');
    $this->scenario->description = $f3->get('POST.description');
   <other fields updated>....
     $this->scenario->save();
 

Note the id field of table scenario is defined as
id integer not null default nextval('scenario_seq');

in release 3.6 this works fine (inserting a new or updating the relevant record)
in 3.7.3-dev the id field is send to postgres as 0 when it is set as null;

Workaround : I stop touching the ID field altogether in my php code
if the id field should be null, I do the a reset
$this->scenario->reset();

otherwise

$this->scenario->load(array('id=?', $id));
I never had to do any change in F3 3.5 or 3.6, only in 3.7
It seems to me that setting the field to null sets it to 0 instead

HTH

[ikkez]

You don't need to change your app code, it was a false assumption with a quick fix I did. I'll try to implement @xfra35 ´s suggestion from #1175 (comment) which then will properly find and track autoincrement fields.

[ikkez]

alright... so I came up with this fix in the latest commit.. if anyone want to test that please too? I've checked it in mysql, sqlite, and postgre... sql server only in fiddle and should be fallback fine to previous behaviour in oracle and others.

[didiergm]

@ikkez At first glance and for my use case, your latest commit seems to be working fine. I leave it in place in my source tree and report back in the next few days to see if there are any other issues.
Note I copied sql.php & mapper.php over the 3.7.3-dev branch
Thanks a lot for the very quick turnaround

[slavino]

until release of 3.7.3 I had to set composer to

    "bcosca/fatfree": "3.7.1",
    "bcosca/fatfree-core": "3.7.1",

Is the last statemt saying that we should rather go for
"bcosca/fatfree": "3.7.3-dev",
"bcosca/fatfree-core": "3.7.3-dev",
?

[ikkez]

"bcosca/fatfree-core": "dev-master",

should be enough, @slavino

[slavino]

Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

Problem 1
- xfra35/f3-cron v1.2.1 requires bcosca/fatfree-core ~3.5 -> satisfiable by bcosca/fatfree-core[3.5.0, 3.5.1, 3.6.1, 3.6.2, 3.6.3, 3.6.4, 3.6.5, 3.7.0, 3.7.1, 3.7.2, v3.6.0] but these conflict with your requirements or minimum-stability.
- xfra35/f3-cron v1.2.0 requires bcosca/fatfree-core 3.* -> satisfiable by bcosca/fatfree-core[3.5.0, 3.5.1, 3.6.1, 3.6.2, 3.6.3, 3.6.4, 3.6.5, 3.7.0, 3.7.1, 3.7.2, v3.6.0] but these conflict with your requirements or minimum-stability.
- xfra35/f3-cron v1.2.1 requires bcosca/fatfree-core ~3.5 -> satisfiable by bcosca/fatfree-core[3.5.0, 3.5.1, 3.6.1, 3.6.2, 3.6.3, 3.6.4, 3.6.5, 3.7.0, 3.7.1, 3.7.2, v3.6.0] but these conflict with your requirements or minimum-stability.
- Installation request for xfra35/f3-cron ^1.2 -> satisfiable by xfra35/f3-cron[v1.2.0, v1.2.1].

aaaargh...

Please perform a release of 3.7.3 :)

[xfra35]

Try: "bcosca/fatfree-core": "dev-master#a82f136 as 3.7.2"

[ikkez]

Latest fix should solve this issue.. Please reopen if problem persists.

[slavino]

So you already released it in 3.7.3 ?

[kumy]

I was about to report the same issue. I'm wondering if there is some estimated release date for 3.7.3?

composer require bcosca/fatfree-core:"dev-master#28e7e75 as 3.7.3-dev" is a saver here 👍