You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I <3 command-line generators. They allow us developers to debug our own code quickly, create better unit tests, and create quick on-the fly scripts to help illustrate problems to other people.
Unfortunately, a data generator is almost never created before a plugin has been completely built, simply because it takes a significant amount of time to build, even though it would be extremely helpful if one was prepared early-on.
I think Berlin could solve this problem.
Ideally, Berlin would have a way to generate data with a PHP method, and possibly a WP_CLI command. It's possible the CLI would need to be in a separate library, since BerlinDB isn't necessarily specific to WordPress.
But how would we associate data with other tables in a generator? Data is usually interconnected in some manner. A good example of this is in AffiliateWP:
A referred transaction needs a referral.
A referral needs an affiliate, a customer, and an order.
An order needs a customer, and products.
An affiliate needs a user ID
A customer needs a user ID
On a basic level, you could create generator methods that would generate affiliates, customers, orders, users, and products individually. This would require 6 separate commands:
Even if you chain these commands together, that's an awful lot of work to build out a test database. It works, it's just not as simple as it could be.
Ideally, it should be possible to configure, and do something more like this:
wp berlindb generate orders --number=10
The simplest solution I can think of is to create a method in the schema, generate that can be overridden by child classes. This would provide a fairly straightforward way to override how generation functionality would work for individual classes.
The text was updated successfully, but these errors were encountered:
I <3 command-line generators. They allow us developers to debug our own code quickly, create better unit tests, and create quick on-the fly scripts to help illustrate problems to other people.
Unfortunately, a data generator is almost never created before a plugin has been completely built, simply because it takes a significant amount of time to build, even though it would be extremely helpful if one was prepared early-on.
I think Berlin could solve this problem.
Ideally, Berlin would have a way to generate data with a PHP method, and possibly a WP_CLI command. It's possible the CLI would need to be in a separate library, since BerlinDB isn't necessarily specific to WordPress.
But how would we associate data with other tables in a generator? Data is usually interconnected in some manner. A good example of this is in AffiliateWP:
A referred transaction needs a referral.
A referral needs an affiliate, a customer, and an order.
An order needs a customer, and products.
An affiliate needs a user ID
A customer needs a user ID
On a basic level, you could create generator methods that would generate affiliates, customers, orders, users, and products individually. This would require 6 separate commands:
wp berlindb generate users --number=10
wp berlindb generate customers --number=1 --users="1,2,3,4,5,6,7,8,9,10"
wp berlindb generate affiliates --number=1 --users="1,2,3,4,5,6,7,8,9,10"
wp berlindb generate products --number=10
wp berlindb generate orders --number=10 --products="1,2,3,3,4,5,6,7,8,9,10"
wp berlindb generate referrals --number=10 --orders="1,2,3,4,5,6,7,8,9,10" --affiliates=1 -- customers=1
Even if you chain these commands together, that's an awful lot of work to build out a test database. It works, it's just not as simple as it could be.
Ideally, it should be possible to configure, and do something more like this:
wp berlindb generate orders --number=10
The simplest solution I can think of is to create a method in the schema,
generate
that can be overridden by child classes. This would provide a fairly straightforward way to override how generation functionality would work for individual classes.The text was updated successfully, but these errors were encountered: